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Preface 


CMMI®  (Capability  Maturity  Model®  Integration)  is  a  process 
improvement  maturity  model  for  the  development  of  products  and 
services.  It  consists  of  best  practices  that  address  development  and 
maintenance  activities  that  cover  the  product  lifecycle  from  conception 
through  delivery  and  maintenance. 

This  latest  iteration  of  the  model  as  represented  herein  integrates 
bodies  of  knowledge  that  are  essential  for  development  and 
maintenance,  but  that  have  been  addressed  separately  in  the  past, 
such  as  software  engineering,  systems  engineering,  hardware  and 
design  engineering,  the  engineering  “-ilities,”  and  acquisition.  The  prior 
designations  of  CMMI  for  systems  engineering  and  software 
engineering  (CMMI-SE/SW)  are  superseded  by  the  title  “CMMI  for 
Development”  to  truly  reflect  the  comprehensive  integration  of  these 
bodies  of  knowledge  and  the  application  of  the  model  within  the 
organization.  CMMI  for  Development  (CMMI-DEV)  provides  a 
comprehensive  integrated  solution  for  development  and  maintenance 
activities  applied  to  products  and  services. 

CMMI  for  Development,  Version  1.2  is  a  continuation  and  update  of 
CMMI  version  1.1  and  has  been  facilitated  by  the  concept  of  CMMI 
“constellations”  wherein  a  set  of  core  components  can  be  augmented 
by  additional  material  to  provide  application-specific  models  with  highly 
common  content.  CMMI-DEV  is  the  first  of  such  constellations  and 
represents  the  development  area  of  interest. 


Purpose 


The  purpose  of  CMMI  for  Development  is  to  help  organizations  improve 
their  development  and  maintenance  processes  for  both  products  and 
services.  CMMI  for  Development  is  a  collection  of  best  practices  that  is 
generated  from  the  CMMI  Framework.1  The  CMMI  Framework  supports 
the  CMMI  Product  Suite  by  allowing  multiple  models,  training  courses, 
and  appraisal  methods  to  be  generated  that  support  specific  areas  of 
interest. 


1  The  CMMI  Framework  is  the  basic  structure  that  organizes  CMMI  components  and  combines  them  into 
CMMI  constellations  and  models. 
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A  constellation  is  a  collection  of  CMMI  components  that  includes  a 
model,  its  training  materials,  and  appraisal-related  documents  for  an 
area  of  interest.  Currently  there  are  three  planned  constellations 
supported  by  the  version  1.2  model  framework:  development,  services, 
and  acquisition.  “Additions”  are  used  to  expand  constellations  for 
specific  additional  content. 

This  document  contains  the  CMMI  for  Development  constellation  and 
contains  both  the  base  CMMI-DEV  as  well  as  CMMI-DEV  with  the  IPPD 
addition  (CMMI-DEV+IPPD). 

If  you  are  not  using  IPPD,  ignore  the  information  that  is  marked  “IPPD 
Addition,”  and  you  will  be  using  the  CMMI  for  Development  model. 

Unlike  CMMI  version  1.1,  there  is  but  a  single  model  document  that 
describes  both  the  staged  and  continuous  approaches  to  process 
improvement  versus  the  prior  use  of  two  representations  of  staged  and 
continuous  in  separate  documents.  This  consolidated  presentation  of 
model  material  for  both  approaches  was  first  used  in  the  book,  CMMI: 
Guidelines  for  Process  Integration  and  Product  Improvement.  Thanks  to 
Peter  Gordon,  publishing  partner  at  Addison-Wesley  Professional,  and 
the  book’s  authors,  Mary  Beth  Chrissis,  Mike  Konrad,  and  Sandy 
Shrum,  we  were  able  to  use  the  book’s  manuscript  as  the  basis  for 
developing  CMMI  version  1.2  [Chrissis  2003], 
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reviewing  all  proposed  changes  to  the  baseline  and  approving  only 
those  changes  that  satisfy  the  identified  issues  and  meet  the  criteria  for 
the  upcoming  release. 

Members  of  these  groups  that  were  involved  in  developing  CMMI  vl  .2, 
are  listed  in  Appendix  C. 


Audience 


The  audience  for  this  model  includes  anyone  interested  in  process 
improvement  in  a  development  and  maintenance  environment.  Whether 
you  are  familiar  with  the  concept  of  Capability  Maturity  Models  or 
whether  you  are  seeking  information  to  get  started  on  your 
improvement  efforts,  this  document  will  be  useful  to  you. 

This  model  is  also  intended  for  people  who  want  to  use  an  appraisal2  to 
see  where  they  are,  those  who  already  know  what  they  want  to 
improve,  and  those  who  are  just  getting  started  and  want  to  develop  a 
general  understanding  of  the  CMMI  for  Development  constellation. 


Organization  of  This  Document 


This  document  is  available  on  the  SEI  Web  site3  and  serves  as  a  guide 

for  improvement  of  organizational  processes.  It  is  organized  into  three 

main  parts: 

•  Part  One — About  CMMI  for  Development 

•  Part  Two — Generic  Goals  and  Generic  Practices,  and  the  Process 
Areas 

•  Part  Three — The  Appendices  and  Glossary 

Part  One,  “About  CMMI  for  Development,”  consists  of  five  chapters: 

•  Chapter  1 ,  “Introduction,”  offers  a  broad  view  of  CMMI  and  the 
CMMI  for  Development  constellation.  It  introduces  you  to  the 
concepts  of  process  improvement,  and  describes  the  history  of 
models  used  for  process  improvement  and  different  process 
improvement  approaches. 

•  Chapter  2,  “Process  Area  Components,”  describes  all  of  the 
components  of  the  CMMI  for  Development  process  areas. 


2  An  appraisal  is  an  examination  of  one  or  more  processes  by  a  trained  team  of  professionals  using  a  reference 
model  (e.g.,  CMMI)  as  the  basis  for  determining  strengths  and  weaknesses. 

3  The  SEI  Web  site  is  located  at  http://www.sei.cmu.edu. 
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•  Chapter  3,  “Tying  It  All  Together,”  assembles  the  model 
components  and  explains  the  concepts  of  maturity  levels  and 
capability  levels. 

•  Chapter  4,  “Relationships  among  Process  Areas,”  provides  insight 
into  the  meaning  and  interactions  of  the  CMMI  for  Development 
process  areas. 

•  Chapter  5,  “Using  CMMI  Models,”  describes  paths  to  adoption  and 
use  of  CMMI  for  process  improvement  and  benchmarking. 

Part  Two,  “Generic  Goals  and  Generic  Practices,  and  the  Process 
Areas,”  contains  all  of  the  CMMI  for  Development  constellation’s 
required  and  expected  components.  It  also  contains  related  informative 
components,  including  component  names,  subpractices,  notes,  and 
typical  work  products. 

Part  Two  contains  23  sections.  The  first  section  contains  the  generic 
goals  and  practices,  including  a  description  of  how  they  are  used  and 
how  they  relate  to  the  process  areas.  The  remaining  22  sections  each 
represent  one  of  the  CMMI  for  Development  process  areas.4  To  make 
these  process  areas  easy  to  find,  they  are  organized  alphabetically  by 
process  area  acronym.  Each  section  contains  descriptions  of  goals, 
best  practices,  and  examples. 

Part  Three,  “The  Appendices  and  Glossary,”  consists  of  four  information 
resources: 

•  Appendix  A,  “References,”  contains  references  you  can  use  to 
locate  documented  sources  of  information  such  as  reports,  process 
improvement  models,  industry  standards,  and  books  that  are 
related  to  CMMI  for  Development. 

•  Appendix  B,  “Acronyms,”  defines  the  acronyms  used  herein. 

•  Appendix  C,  “CMMI  for  Development  Project  Participants,”  contains 
lists  of  people  and  their  organizations  who  participated  in  the 
development  of  CMMI  for  Development,  Version  1 .2. 

•  The  “Glossary”  defines  many  of  the  terms  used  in  CMMI. 


How  to  Use  This  Document 


Whether  you  are  new  to  process  improvement,  new  to  CMMI,  or 
already  familiar  with  CMMI,  Part  One  can  help  you  understand  why 
CMMI  for  Development  is  the  best  model  to  use  for  improving  your 
development  and  maintenance  processes. 


4  A  “process  area”  is  a  cluster  of  related  best  practices  in  an  area,  which  when  implemented  collectively,  satisfy 
a  set  of  goals  considered  important  for  making  significant  improvement  in  that  area.  We  will  cover  this 
concept  in  detail  in  Chapter  2. 
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If  you  are  new  to  process  improvement  or  new  to  the  CMM®  concept, 
we  suggest  that  you  read  Chapter  1,  “Introduction,”  first.  Chapter  1  will 
give  you  an  overview  of  process  improvement  and  explain  what  CMMI 
is  all  about. 

Next,  skim  Part  Two,  including  generic  goals  and  practices  as  well  as 
specific  goals  and  practices,  to  get  a  feel  for  the  scope  of  the  best 
practices  contained  in  the  model.  Pay  closest  attention  to  the  purpose 
and  introductory  notes  at  the  beginning  of  each  section. 

In  Part  Three,  look  through  the  references  in  Appendix  A  and  select 
additional  sources  you  think  would  be  beneficial  to  read  before  moving 
forward  with  using  CMMI  for  Development.  Read  through  the  acronyms 
and  glossary  to  become  familiar  with  the  language  of  CMMI.  Then,  go 
back  and  read  the  details  of  Part  Two. 

Readers  Experienced  with  Process  Improvement 


If  you  are  new  to  CMMI  but  have  experience  with  other  process 
improvement  models,  such  as  the  Software  CMM  (version  1 .1 )  or  the 
Systems  Engineering  Capability  Model  (i.e.,  EIA  731),  you  will 
immediately  recognize  many  similarities  [EIA  1998], 

We  recommend  that  you  read  Part  One  to  understand  how  CMMI  is 
different  from  other  process  improvement  models,  but  you  may  want  to 
read  some  of  the  sections  more  quickly  than  others.  Read  Part  Two 
with  an  eye  open  for  best  practices  you  recognize  from  the  models  you 
have  already  tried.  Identifying  familiar  material  gives  you  a  feel  for  what 
is  new  and  what  has  been  carried  over  from  the  model  you  already 
know. 

Next,  review  the  glossary  to  understand  how  some  terminology  may 
differ  from  that  used  in  the  process  improvement  model  you  know. 
Many  concepts  will  be  repeated,  but  they  may  be  called  something 
different. 

Readers  Familiar  with  CMMI 


If  you  have  reviewed  or  used  a  CMMI  model  before,  you  will  quickly 
recognize  the  CMMI  concepts  discussed  and  the  best  practices 
presented.  The  differences  between  version  1.2  and  version  1.1  are 
explained  in  detail  on  the  SEI  Web  site  in  the  version  1.2  release  notes. 
These  differences  reflect  the  enhancements  suggested  by  the  users  of 
version  1.1. 
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The  following  improvements  were  made  to  version  1.2: 

•  Both  representations  are  presented  together. 

•  The  advanced  practice  and  common  feature  concepts  have  been 
removed. 

•  The  generic  goal  and  practice  descriptions  were  moved  to  Part 
Two. 

•  Hardware  amplifications  were  added. 

•  All  definitions  were  consolidated  in  the  glossary. 

•  IPPD  practices  were  consolidated  and  simplified.  There  are  no 
longer  any  separate  IPPD  process  areas. 

•  Supplier  Agreement  Management  (SAM)  and  Integrated  Supplier 
Management  (ISM)  were  consolidated  and  Supplier  Sourcing  was 
removed. 

•  Generic  practice  (GP)  elaborations  were  added  to  the  level  3  GPs. 

•  An  explanation  of  how  process  areas  support  the  implementation  of 
GPs  was  added. 

•  Material  was  added  to  ensure  that  standard  processes  are  deployed 
to  projects  at  their  startup. 


Additional  Information  and  Reader  Feedback 


You  can  find  additional  information  from  various  other  sources  about 
CMMI,  such  as  the  background  and  history  of  the  CMMI  models,  as  well 
as  the  benefits  of  using  CMMI  models.  Many  of  these  sources  are  listed 
in  Appendix  A  and  are  also  published  on  the  CMMI  Web  site — 
http://www.sei.cmu.edu/cmmi/  [SEI  2], 

Suggestions  for  improving  CMMI  are  welcome.  For  information  on  how 
to  provide  feedback,  see  the  CMMI  Web  site  at 

http://www.sei.cmu.edu/cmmi/models/change-requests.html.  If  you  have 
questions  about  CMMI,  send  an  email  to  cmmi- 
comments@sei.cmu.edu. 
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1  Introduction 


Now,  more  than  ever,  companies  want  to  deliver  products  and  services 
better,  faster,  and  cheaper.  At  the  same  time,  in  the  high-technology 
environment  of  the  twenty-first  century,  nearly  all  organizations  have 
found  themselves  building  increasingly  complex  products  and  services. 
Today,  a  single  company  usually  does  not  develop  all  the  components 
that  compose  a  product  or  service.  More  commonly,  some  components 
are  built  in-house  and  some  are  acquired;  then  all  the  components  are 
integrated  into  the  final  product  or  service.  Organizations  must  be  able 
to  manage  and  control  this  complex  development  and  maintenance 
process. 

The  problems  these  organizations  address  today  involve  enterprise¬ 
wide  solutions  that  require  an  integrated  approach.  Effective 
management  of  organizational  assets  is  critical  to  business  success.  In 
essence,  these  organizations  are  product  and  service  developers  that 
need  a  way  to  manage  an  integrated  approach  to  their  development 
activities  as  part  of  achieving  their  business  objectives. 

In  the  current  marketplace,  there  are  maturity  models,  standards, 
methodologies,  and  guidelines  that  can  help  an  organization  improve 
the  way  it  does  business.  However,  most  available  improvement 
approaches  focus  on  a  specific  part  of  the  business  and  do  not  take  a 
systemic  approach  to  the  problems  that  most  organizations  are  facing. 
By  focusing  on  improving  one  area  of  a  business,  these  models  have 
unfortunately  perpetuated  the  stovepipes  and  barriers  that  exist  in 
organizations. 

Capability  Maturity  Model®  Integration  (CMMI®)  provides  an  opportunity 
to  avoid  or  eliminate  these  stovepipes  and  barriers  through  integrated 
models  that  transcend  disciplines.  CMMI  for  Development  consists  of 
best  practices  that  address  development  and  maintenance  activities 
applied  to  products  and  services.  It  addresses  practices  that  cover  the 
product’s  lifecycle  from  conception  through  delivery  and  maintenance. 
The  emphasis  is  on  the  work  necessary  to  build  and  maintain  the  total 
product. 
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About  Capability  Maturity  Models 


In  its  research  to  help  organizations  develop  and  maintain  quality 
products  and  services,  the  Software  Engineering  Institute  (SEI)  has 
found  several  dimensions  that  an  organization  can  focus  on  to  improve 
its  business.  Figure  1.1  illustrates  the  three  critical  dimensions  that 
organizations  typically  focus  on:  people,  procedures  and  methods,  and 
tools  and  equipment. 


Procedures  and  methods 
defining  the  relationship  of 
tasks 


B 


People 
with  skills, 
training,  and 
motivation 


Tools  and 
equipment 


Figure  1.1:  The  Three  Critical  Dimensions 

But  what  holds  everything  together?  It  is  the  processes  used  in  your 
organization.  Processes  allow  you  to  align  the  way  you  do  business. 
They  allow  you  to  address  scalability  and  provide  a  way  to  incorporate 
knowledge  of  how  to  do  things  better.  Processes  allow  you  to  leverage 
your  resources  and  to  examine  business  trends. 

This  is  not  to  say  that  people  and  technology  are  not  important.  We  are 
living  in  a  world  where  technology  is  changing  by  an  order  of  magnitude 
every  ten  years.  Similarly,  people  typically  work  for  many  companies 
throughout  their  careers.  We  live  in  a  dynamic  world.  A  focus  on 
process  provides  the  infrastructure  necessary  to  deal  with  an  ever- 
changing  world,  and  to  maximize  the  productivity  of  people  and  the  use 
of  technology  to  be  more  competitive. 


Manufacturing  has  long  recognized  the  importance  of  process 
effectiveness  and  efficiency.  Today,  many  organizations  in 
manufacturing  and  service  industries  recognize  the  importance  of 
quality  processes.  Process  helps  an  organization’s  workforce  meet 
business  objectives  by  helping  them  work  smarter,  not  harder,  and  with 
improved  consistency.  Effective  processes  also  provide  a  vehicle  for 


4 


Introduction 


CMMI  for  Development 
Version  1.2 


introducing  and  using  new  technology  in  a  way  that  best  meets  the 
business  objectives  of  the  organization. 

In  the  1930s,  Walter  Shewhart  began  work  in  process  improvement  with 
his  principles  of  statistical  quality  control  [Shewhart  1931],  These 
principles  were  refined  by  W.  Edwards  Deming  [Deming  1986],  Phillip 
Crosby  [Crosby  1979],  and  Joseph  Juran  [Juran  1988],  Watts 
Humphrey,  Ron  Radice,  and  others  extended  these  principles  even 
further  and  began  applying  them  to  software  in  their  work  at  IBM  and 
the  SEI  [Humphrey  1989],  Humphrey’s  book,  Managing  the  Software 
Process,  provides  a  description  of  the  basic  principles  and  concepts  on 
which  many  of  the  capability  maturity  models  (CMMs®)  are  based. 

The  SEI  has  taken  the  process  management  premise,  “the  quality  of  a 
system  or  product  is  highly  influenced  by  the  quality  of  the  process  used 
to  develop  and  maintain  it,”  and  defined  CMMs  that  embody  this 
premise.  The  belief  in  this  premise  is  seen  worldwide  in  quality 
movements,  as  evidenced  by  the  International  Organization  for 
Standardization/International  Electrotechnical  Commission  (ISO/IEC) 
body  of  standards. 

CMMs  focus  on  improving  processes  in  an  organization.  They  contain 
the  essential  elements  of  effective  processes  for  one  or  more 
disciplines  and  describe  an  evolutionary  improvement  path  from  ad  hoc, 
immature  processes  to  disciplined,  mature  processes  with  improved 
quality  and  effectiveness. 

The  SEI  created  the  first  CMM  designed  for  software  organizations  and 
published  it  in  a  book,  The  Capability  Maturity  Model:  Guidelines  for 
Improving  the  Software  Process  [SEI  1995], 

The  SEI’s  book  applied  the  principles  introduced  almost  a  century  ago 
to  this  never-ending  cycle  of  process  improvement.  The  value  of  this 
process  improvement  approach  has  been  confirmed  over  time. 
Organizations  have  experienced  increased  productivity  and  quality, 
improved  cycle  time,  and  more  accurate  and  predictable  schedules  and 
budgets  [Gibson  2006], 


Evolution  of  CMMI 


Since  1991,  CMMs  have  been  developed  for  myriad  disciplines.  Some 
of  the  most  notable  include  models  for  systems  engineering,  software 
engineering,  software  acquisition,  workforce  management  and 
development,  and  integrated  product  and  process  development  (IPPD). 

Although  these  models  have  proven  useful  to  many  organizations  in 
different  industries,  the  use  of  multiple  models  has  been  problematic. 
Many  organizations  would  like  their  improvement  efforts  to  span 
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different  groups  in  their  organizations.  However,  the  differences  among 
the  discipline-specific  models  used  by  each  group,  including  their 
architecture,  content,  and  approach,  have  limited  these  organizations’ 
capabilities  to  broaden  their  improvements  successfully.  Further, 
applying  multiple  models  that  are  not  integrated  within  and  across  an 
organization  is  costly  in  terms  of  training,  appraisals,  and  improvement 
activities. 

The  CMM  lntegrationSM  project  was  formed  to  sort  out  the  problem  of 
using  multiple  CMMs.  The  CMMI  Product  Team’s  initial  mission  was  to 
combine  three  source  models: 

1 .  The  Capability  Maturity  Model  for  Software  (SW-CMM)  v2.0  draft  C 
[SEI  1997b] 

2.  The  Systems  Engineering  Capability  Model  (SECM)  [EIA  1998]5 

3.  The  Integrated  Product  Development  Capability  Maturity  Model 
(IPD-CMM)  vO.98  [SEI  1997a] 


The  combination  of  these  models  into  a  single  improvement  framework 
was  intended  for  use  by  organizations  in  their  pursuit  of  enterprise-wide 
process  improvement. 

These  three  source  models  were  selected  because  of  their  widespread 
adoption  in  the  software  and  systems  engineering  communities  and 
because  of  their  different  approaches  to  improving  processes  in  an 
organization. 

Using  information  from  these  popular  and  well-regarded  models  as 
source  material,  the  CMMI  Product  Team  created  a  cohesive  set  of 
integrated  models  that  can  be  adopted  by  those  currently  using  the 
source  models,  as  well  as  by  those  new  to  the  CMM  concept.  Hence, 
CMMI  is  a  result  of  the  evolution  of  the  SW-CMM,  the  SECM,  and  the 
IPD-CMM. 

Developing  a  set  of  integrated  models  involved  more  than  simply 
combining  existing  model  materials.  Using  processes  that  promote 
consensus,  the  CMMI  Product  Team  built  a  framework  that 
accommodates  multiple  disciplines  and  is  flexible  enough  to  support  the 
different  approaches  of  the  source  models  [Ahern  2003]. 


5  The  Systems  Engineering  Capability  Model  is  also  known  as  Electronic  Industries  Alliance  731  (EIA  731). 
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Figure  1 .2:  The  History  of  CMMs 


Since  the  release  of  CMMI  vl  .1 ,  we  have  seen  that  this  improvement 
framework  can  be  applied  to  other  areas  of  interest  [SEI  2002a,  SEI 
2002b],  To  apply  to  multiple  areas  of  interest,  the  framework  groups 
best  practices  into  what  we  call  “constellations.”  A  constellation  is  a 
collection  of  CMMI  components  that  are  used  to  build  models,  training 
materials,  and  appraisal  documents. 

Recently,  the  CMMI  model  architecture  was  improved  to  support 
multiple  constellations  and  the  sharing  of  best  practices  among 
constellations  and  their  member  models.  Work  has  begun  on  two  new 
constellations:  one  for  services  (CMMI  for  Services)  and  the  other  for 
acquisition  (CMMI  for  Acquisition).  Although  CMMI  for  Development 
incorporates  the  development  of  services,  including  the  combination  of 
components,  consumables,  and  people  intended  to  meet  service 
requirements,  it  differs  from  the  planned  CMMI  for  Services  (CMMI- 
SVC),  which  focuses  on  the  delivery  of  services.  The  CMMI  models  that 
have  been  available  in  the  community  prior  to  2006  are  now  considered 
part  of  the  CMMI  for  Development  constellation. 


CMMI  for  Development 


The  CMMI  for  Development  constellation  consists  of  two  models:  CMMI 
for  Development  +IPPD  and  CMMI  for  Development  (without  IPPD). 
Both  models  share  much  of  their  material  and  are  identical  in  these 
shared  areas.  However,  CMMI  for  Development  +IPPD  contains 
additional  goals  and  practices  that  cover  IPPD. 
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Currently,  only  one  model  is  published  since  the  CMMI  for  Development 
+IPPD  model  contains  the  full  complement  of  practices  available  in  this 
constellation,  and  you  can  derive  the  other  model  from  this  material.  If 
you  are  not  using  IPPD,  ignore  the  information  that  is  marked  “IPPD 
Addition,”  and  you  will  be  using  the  CMMI  for  Development  model.  If  the 
need  arises  or  the  development  constellation  is  expanded,  the 
architecture  will  allow  other  models  to  be  generated  and  published. 

CMMI  for  Development  is  the  designated  successor  of  the  three  source 
models.  The  SEI  has  retired  the  Software  CMM  and  the  IPD-CMM.  EIA 
has  retired  the  SECM.  All  three  of  these  models  are  succeeded  by 
CMMI  for  Development. 

The  best  practices  in  the  CMMI  models  have  gone  through  an  extensive 
review  process.  CMMI  version  0.2  was  publicly  reviewed  and  used  in 
pilot  activities. 

The  CMMI  Product  Team  evaluated  more  than  3,000  change  requests 
to  create  CMMI  version  1 .0.  Shortly  thereafter,  version  1 .02  was 
released,  which  incorporated  several  minor  improvements. 

Version  1.1  incorporated  improvements  guided  by  feedback  from  early 
use,  with  more  than  1,500  change  requests  submitted  as  part  of  the 
public  review,  and  hundreds  of  comments  as  part  of  the  change  control 
process. 

CMMI  version  1.2  was  developed  using  input  from  nearly  2,000  change 
requests  submitted  by  CMMI  users.  More  than  750  of  those  requests 
were  directed  at  CMMI  model  content.  As  you  can  see,  not  only  is 
CMMI  widely  adopted,  but  it  is  improved  based  on  the  feedback 
received  from  the  community. 


The  Scope  of  CMMI  for  Development 


CMMI  for  Development  is  a  reference  model  that  covers  the 
development  and  maintenance  activities  applied  to  both  products  and 
services.  Organizations  from  many  industries,  including  aerospace, 
banking,  computer  hardware,  software,  defense,  automobile 
manufacturing,  and  telecommunications,  use  CMMI  for  Development. 

Models  in  the  CMMI  for  Development  constellation  contain  practices 
that  cover  project  management,  process  management,  systems 
engineering,  hardware  engineering,  software  engineering,  and  other 
supporting  processes  used  in  development  and  maintenance.  The 
CMMI  for  Development  +IPPD  model  also  covers  the  use  of  integrated 
teams  for  development  and  maintenance  activities. 
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The  Group  of  IPPD  Additions 


In  CMMI,  “additions”  are  used  to  include  material  that  may  be  of  interest 
to  particular  users.  For  the  CMMI  for  Development  constellation, 
additional  material  was  included  to  address  IPPD. 

The  IPPD  group  of  additions  covers  an  IPPD  approach  that  includes 
practices  that  help  organizations  achieve  the  timely  collaboration  of 
relevant  stakeholders  throughout  the  life  of  the  product  to  satisfy 
customers’  needs,  expectations,  and  requirements  [DoD  1996],  When 
using  processes  that  support  an  IPPD  approach,  you  should  integrate 
these  processes  with  other  processes  in  the  organization.  To  support 
those  using  IPPD-related  processes,  the  CMMI  for  Development 
constellation  allows  organizations  to  optionally  select  the  IPPD  group  of 
additions. 

When  you  select  CMMI  for  Development  +IPPD,  you  are  selecting  the 
CMMI  for  Development  model  plus  all  the  IPPD  additions.  When  you 
select  CMMI  for  Development,  you  are  selecting  the  model  without  the 
IPPD  additions.  In  the  text  in  Part  One  of  this  document,  we  may  use 
“CMMI  for  Development”  to  refer  to  either  of  these  models,  for  the  sake 
of  brevity. 


Resolving  Different  Approaches  of  CMMs 


The  definition  of  a  CMM  allows  the  community  to  develop  models 
supporting  different  approaches  to  process  improvement.  As  long  as  a 
model  contains  the  essential  elements  of  effective  processes  for  one  or 
more  disciplines  and  describes  an  evolutionary  improvement  path  from 
ad  hoc,  immature  processes  to  disciplined,  mature  processes  with 
improved  quality  and  effectiveness,  it  is  considered  a  CMM.  CMMI 
enables  you  to  approach  process  improvement  and  appraisals  using 
two  different  representations:  continuous  and  staged. 

The  continuous  representation  enables  an  organization  to  select  a 
process  area  (or  group  of  process  areas)  and  improve  processes 
related  to  it.  This  representation  uses  capability  levels  to  characterize 
improvement  relative  to  an  individual  process  area. 

The  staged  representation  uses  predefined  sets  of  process  areas  to 
define  an  improvement  path  for  an  organization.  This  improvement  path 
is  characterized  by  maturity  levels.  Each  maturity  level  provides  a  set  of 
process  areas  that  characterize  different  organizational  behaviors. 
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Choosing  a  Representation 


If  you  are  new  to  process  improvement  and  are  not  familiar  with  either 
the  staged  or  the  continuous  representation,  you  cannot  go  wrong  if  you 
choose  one  representation  or  the  other.  There  are  many  valid  reasons 
to  select  either  representation. 

If  you  have  been  using  a  CMM  and  you  are  familiar  with  a  particular 
representation,  we  suggest  that  you  continue  to  use  that  representation 
because  it  will  make  the  transition  to  CMMI  easier.  Once  you  have 
become  completely  comfortable  with  CMMI,  you  might  then  decide  to 
use  the  other  representation. 

Because  each  representation  has  advantages  over  the  other,  some 
organizations  use  both  representations  to  address  particular  needs  at 
various  times  in  their  improvement  programs.  In  the  following  sections, 
we  provide  the  advantages  and  disadvantages  of  each  representation 
to  help  you  decide  which  representation  is  best  for  your  organization. 

Continuous  Representation 


The  continuous  representation  offers  maximum  flexibility  when  using  a 
CMMI  model  for  process  improvement.  An  organization  may  choose  to 
improve  the  performance  of  a  single  process-related  trouble  spot,  or  it 
can  work  on  several  areas  that  are  closely  aligned  to  the  organization’s 
business  objectives.  The  continuous  representation  also  allows  an 
organization  to  improve  different  processes  at  different  rates.  There  are 
some  limitations  on  an  organization’s  choices  because  of  the 
dependencies  among  some  process  areas. 

If  you  know  the  processes  that  need  to  be  improved  in  your 
organization  and  you  understand  the  dependencies  among  the  process 
areas  described  in  CMMI,  the  continuous  representation  is  a  good 
choice  for  your  organization. 

Staged  Representation 


The  staged  representation  offers  a  systematic,  structured  way  to 
approach  model-based  process  improvement  one  stage  at  a  time. 
Achieving  each  stage  ensures  that  an  adequate  process  infrastructure 
has  been  laid  as  a  foundation  for  the  next  stage. 

Process  areas  are  organized  by  maturity  levels  that  take  some  of  the 
guess  work  out  of  process  improvement.  The  staged  representation 
prescribes  an  order  for  implementing  process  areas  according  to 
maturity  levels,  which  define  the  improvement  path  for  an  organization 
from  the  initial  level  to  the  optimizing  level.  Achieving  each  maturity 
level  ensures  that  an  adequate  improvement  foundation  has  been  laid 
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for  the  next  maturity  level  and  allows  for  lasting,  incremental 
improvement. 

If  you  do  not  know  where  to  start  and  which  processes  to  choose  to 
improve,  the  staged  representation  is  a  good  choice  for  you.  It  gives 
you  a  specific  set  of  processes  to  improve  at  each  stage  that  has  been 
determined  through  more  than  a  decade  of  research  and  experience 
with  process  improvement. 


Comparison  of  the  Continuous  and  Staged  Representations 


Table  1.1  compares  the  advantages  of  each  representation  and  may 
assist  you  with  determining  which  representation  is  right  for  your 
organization. 

Table  1.1  Comparative  Advantages  of  Continuous  and  Staged 
Representations 

Continuous  Representation 

Staged  Representation 

Grants  explicit  freedom  to  select  the 
order  of  improvement  that  best  meets 
the  organization’s  business  objec¬ 
tives  and  mitigates  the  organization’s 
areas  of  risk 

Enables  organizations  to  have  a  pre¬ 
defined  and  proven  improvement  path 

Enables  increased  visibility  of  the 
capability  achieved  in  each  individual 
process  area 

Focuses  on  a  set  of  processes  that 
provide  an  organization  with  a  spe¬ 
cific  capability  that  is  characterized  by 
each  maturity  level 

Allows  improvements  of  different 
processes  to  be  performed  at  differ¬ 
ent  rates 

Summarizes  process  improvement 
results  in  a  simple  form — a  single 
maturity  level  number 

Reflects  a  newer  approach  that  does 
not  yet  have  the  data  to  demonstrate 
its  ties  to  return  on  investment 

Builds  on  a  relatively  long  history  of 
use  that  includes  case  studies  and 
data  that  demonstrate  return  on  in¬ 
vestment 

Factors  in  Your  Decision 

Three  categories  of  factors  that  may  influence  your  decision  when 
selecting  a  representation  are  business,  culture,  and  legacy. 

Business  Factors 

Introduction 


An  organization  with  mature  knowledge  of  its  own  business  objectives 
is  likely  to  have  a  strong  mapping  of  its  processes  to  its  business 
objectives.  Such  an  organization  may  find  the  continuous 


11 


representation  useful  to  appraise  its  processes  and  in  determining  how 
well  the  organization’s  processes  support  and  meet  its  business 
objectives. 

If  an  organization  with  a  product-line  focus  decides  to  improve 
processes  across  the  entire  organization,  it  might  be  served  best  by  the 
staged  representation.  The  staged  representation  will  help  an 
organization  select  the  critical  processes  to  focus  on  for  improvement. 

The  same  organization  may  opt  to  improve  processes  by  product  line. 

In  that  case,  it  might  select  the  continuous  representation — and  a 
different  appraised  rating  of  capability  might  be  achieved  for  each 
product  line.  Both  approaches  are  valid.  The  most  important 
consideration  is  which  business  objectives  you  would  like  your  process 
improvement  program  to  support  and  how  these  business  objectives 
align  with  the  two  representations. 

Cultural  Factors 


Cultural  factors  to  consider  when  selecting  a  representation  have  to  do 
with  an  organization’s  capability  to  deploy  a  process  improvement 
program.  For  instance,  an  organization  might  select  the  continuous 
representation  if  the  corporate  culture  is  process  based  and 
experienced  in  process  improvement  or  has  a  specific  process  that 
needs  to  be  improved  quickly.  An  organization  that  has  little  experience 
in  process  improvement  may  choose  the  staged  representation,  which 
provides  additional  guidance  on  the  order  in  which  changes  should 
occur. 

Legacy 

If  an  organization  has  experience  with  another  model  that  has  a  staged 
representation,  it  may  be  wise  to  continue  with  the  staged 
representation  when  using  CMMI,  especially  if  it  has  invested  resources 
and  deployed  processes  across  the  organization  that  are  associated 
with  a  staged  representation.  The  same  is  true  for  the  continuous 
representation. 

Why  Not  Both  Representations? 


Whether  used  for  process  improvement  or  appraisals,  both 
representations  are  designed  to  offer  essentially  equivalent  results. 
Nearly  all  of  the  CMMI  model  content  is  common  to  both 
representations.  Therefore,  an  organization  need  not  select  one 
representation  over  another. 

In  fact,  an  organization  may  find  utility  in  both  representations.  It  is  rare 
that  an  organization  will  implement  either  representation  exactly  as 
prescribed.  Organizations  that  are  successful  in  process  improvement 
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often  define  an  improvement  plan  that  focuses  on  the  unique  needs  of 
that  organization  and  therefore  use  the  principles  of  both  the  staged 
and  the  continuous  representations. 

For  example,  organizations  that  select  the  staged  representation  and 
are  at  maturity  level  1  often  implement  the  maturity  level  2  process 
areas  but  also  the  Organizational  Process  Focus  process  area,  which  is 
included  at  maturity  level  3.  Another  example  is  an  organization  that 
chooses  the  continuous  representation  for  guiding  its  internal  process 
improvement  effort  and  then  chooses  the  staged  representation  to 
conduct  an  appraisal. 


Your  Approach  to  Process  Improvement 


To  demonstrate  how  to  use  this  model,  let  us  look  at  two  different 
scenarios.  Scenario  1  is  an  electronic  systems  developer  that  wants  to 
improve  its  product  development  processes  using  a  continuous 
approach.  Scenario  2  is  a  software  development  company  that  uses 
IPPD,  has  been  using  the  Software  CMM,  and  now  wants  to  use  CMMI. 
This  company  most  recently  has  been  rated  at  maturity  level  3  using  the 
Software  CMM  (version  1.1). 

Scenario  1 


In  this  scenario,  you  are  using  a  continuous  approach  and,  therefore, 
you  select  the  processes  that  are  important  to  your  business  objectives. 
Since  there  are  22  process  areas  to  choose  from,  this  is  usually  too 
many  to  focus  on  when  starting  out.  You  may  need  to  narrow  your 
focus.  For  example,  you  may  find  that  your  competitor  always  releases 
its  product  before  yours.  You  may  choose  to  focus  on  improving  your 
engineering  and  project  management  processes. 

Building  on  this  decision,  you  select  all  the  Engineering  process  areas 
as  a  starting  point:  Product  Integration,  Requirements  Development, 
Requirements  Management,  Technical  Solution,  Validation,  and 
Verification.  You  also  select  Project  Planning  and  Project  Monitoring 
and  Control. 

You  may  at  this  point  decide  that  eight  process  areas  are  still  too  many 
to  focus  on  initially,  and  you  decide  that  the  requirements  process  is 
really  where  the  problems  are.  Consequently,  you  select  the 
Requirements  Development  and  Requirements  Management  process 
areas  to  begin  your  improvement  efforts. 

Next  you  decide  how  much  improvement  is  needed  in  the  requirements 
area.  Do  you  have  any  processes  in  place  already?  If  you  do  not,  your 
process  improvement  objective  may  be  to  get  to  capability  level  1 . 
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Do  you  have  your  requirements  development  and  management 
processes  in  place  for  each  project,  but  they  are  not  managed 
processes?  For  example,  policies,  training,  and  tools  are  not 
implemented  to  support  the  processes.  If  your  requirements  processes 
are  in  place  but  there  is  no  supporting  infrastructure,  your  process 
improvement  objective  may  be  to  get  to  capability  level  2. 

Do  you  have  all  your  requirements  development  and  management 
processes  and  their  management  in  place,  but  each  project  performs 
these  processes  differently?  For  example,  your  requirements  elicitation 
process  is  not  performed  consistently  across  the  organization.  If  this  is 
the  case,  your  process  improvement  objective  may  be  to  get  to 
capability  level  3. 

Do  you  consistently  manage  and  perform  your  requirements 
development  and  management  processes  but  do  not  have  an  objective 
way  to  control  and  improve  these  processes?  If  this  is  the  case,  your 
process  improvement  objective  may  be  to  get  to  capability  level  4. 

Do  you  want  to  ensure  that  you  are  selecting  the  right  subprocesses  to 
improve  based  on  quantitative  objectives  to  maximize  your  business?  If 
so,  your  process  improvement  objective  may  be  to  get  to  capability  level 
5  for  selected  processes.  In  the  description  of  each  process  area, 
remember  to  look  for  amplifications  introduced  by  the  phrases  “For 
Hardware  Engineering,”  “For  Systems  Engineering,”  and  “For  Software 
Engineering.”  Use  all  information  that  has  no  specific  markings  and  the 
material  in  the  boxes  labeled  “Continuous  Only.” 

As  you  can  see  from  this  scenario,  you  need  to  understand  which 
processes  need  improvement  and  how  much  you  want  to  mature  each 
process.  This  way  of  proceeding  reflects  the  fundamental  principle 
behind  the  continuous  representation. 

Scenario  2 


In  the  second  scenario,  you  are  a  software  development  company  using 
IPPD,  using  the  Software  CMM,  and  you  want  to  use  CMMI.  You  select 
the  process  areas  at  maturity  levels  2  and  3  and  choose  the  CMMI  for 
Development  +IPPD  model. 

This  selection  includes  the  following  seven  process  areas  at  maturity 
level  2:  Requirements  Management,  Project  Planning,  Project 
Monitoring  and  Control,  Supplier  Agreement  Management, 
Measurement  and  Analysis,  Process  and  Product  Quality  Assurance, 
and  Configuration  Management.  It  also  includes  the  following  1 1 
process  areas  at  maturity  level  3:  Requirements  Development, 

Technical  Solution,  Product  Integration,  Verification,  Validation, 
Organizational  Process  Focus,  Organizational  Process  Definition 
+IPPD,  Organizational  Training,  Integrated  Project  Management  +IPPD, 
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Risk  Management,  and  Decision  Analysis  and  Resolution.  You  will  also 
include  the  IPPD  additions. 

Since  you  have  already  been  rated  at  maturity  level  3  for  the  Software 
CMM,  look  at  the  CMMI  process  areas  that  were  not  in  the  Software 
CMM.  These  process  areas  include  Measurement  and  Analysis, 
Requirements  Development,  Technical  Solution,  Product  Integration, 
Verification,  Validation,  Risk  Management,  and  Decision  Analysis  and 
Resolution.  Determine  if  you  have  these  processes  in  your  organization 
even  though  they  were  not  described  in  the  Software  CMM.  If  any 
processes  in  place  correspond  to  these  process  areas  and  the  other 
process  areas  that  were  in  the  Software  CMM,  perform  a  gap  analysis 
against  the  goals  and  practices  to  make  sure  you  addressed  the  intent 
of  each  CMMI  process  area. 

Remember,  in  each  process  area  you  select,  to  look  for  information 
labeled  “For  Software  Engineering”  and  “IPPD  Addition.”  Use  all 
information  that  has  no  specific  markings,  as  well  as  the  material  in 
boxes  labeled  “Staged  Only.” 

As  you  can  see,  the  information  provided  in  this  document  can  be  used 
in  a  variety  of  ways,  depending  on  your  improvement  needs.  The 
overall  goal  of  CMMI  is  to  provide  a  framework  that  can  share 
consistent  process  improvement  best  practices  and  approaches,  but 
can  be  flexible  enough  to  address  the  rapidly  changing  needs  of  the 
community. 
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2  Process  Area  Components 


This  chapter  describes  the  components  of  each  process  area,  generic 
goal,  and  generic  practice.  Understanding  the  meaning  of  these 
components  is  critical  to  using  the  information  in  Part  Two  effectively.  If 
you  are  unfamiliar  with  Part  Two,  you  may  want  to  skim  the  Generic 
Goals  and  Generic  Practices  section  and  a  couple  of  process  area 
sections  to  get  a  general  feel  for  the  content  and  layout  before  reading 
this  chapter. 


Required,  Expected,  and  Informative  Components 


Model  components  are  grouped  into  three  categories — required, 
expected,  and  informative — that  reflect  how  to  interpret  them. 

Required  Components 


Required  components  describe  what  an  organization  must  achieve  to 
satisfy  a  process  area.  This  achievement  must  be  visibly  implemented 
in  an  organization’s  processes.  The  required  components  in  CMMI  are 
the  specific  and  generic  goals.  Goal  satisfaction  is  used  in  appraisals  as 
the  basis  for  deciding  whether  a  process  area  has  been  achieved  and 
satisfied. 

Expected  Components 


Expected  components  describe  what  an  organization  may  implement  to 
achieve  a  required  component.  Expected  components  guide  those  who 
implement  improvements  or  perform  appraisals.  Expected  components 
include  the  specific  and  generic  practices. 

Before  goals  can  be  considered  satisfied,  either  the  practices  as 
described,  or  acceptable  alternatives  to  them,  are  present  in  the 
planned  and  implemented  processes  of  the  organization. 

Informative  Components 


Informative  components  provide  details  that  help  organizations  get 
started  in  thinking  about  how  to  approach  the  required  and  expected 
components.  Subpractices,  typical  work  products,  amplifications, 
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generic  practice  elaborations,  goal  and  practice  titles,  goal  and  practice 
notes,  and  references  are  examples  of  informative  model  components. 

The  CMMI  glossary  of  terms  is  not  a  required,  expected,  or  informative 
component  of  CMMI  models.  You  should  interpret  the  terms  in  the 
glossary  in  the  context  of  the  model  component  in  which  they  appear. 


Components  Associated  with  Part  Two 


The  model  components  associated  with  Part  Two  can  be  summarized 
to  illustrate  their  relationships,  as  shown  in  Figure  2.1. 


Typical  Work 
Products  , 


3eneric  Practice\ 
Elaborations . 


KEY: 


Figure  2.1:  CMMI  Model  Components 

The  following  sections  provide  detailed  descriptions  of  the  model 
components. 
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Process  Areas 

A  process  area  is  a  cluster  of  related  practices  in  an  area  that,  when 
implemented  collectively,  satisfy  a  set  of  goals  considered  important  for 
making  improvement  in  that  area. 

There  are  22  process  areas,  presented  here  in  alphabetical  order  by 
acronym: 

•  Causal  Analysis  and  Resolution  (CAR) 

•  Configuration  Management  (CM) 

•  Decision  Analysis  and  Resolution  (DAR) 

•  Integrated  Project  Management  +IPPD  (IPM+IPPD)6 

•  Measurement  and  Analysis  (MA) 

•  Organizational  Innovation  and  Deployment  (OID) 

•  Organizational  Process  Definition  +IPPD  (OPD+IPPD)6 

•  Organizational  Process  Focus  (OPF) 

•  Organizational  Process  Performance  (OPP) 

•  Organizational  Training  (OT) 

•  Product  Integration  (PI) 

•  Project  Monitoring  and  Control  (PMC) 

•  Project  Planning  (PP) 

•  Process  and  Product  Quality  Assurance  (PPQA) 

•  Quantitative  Project  Management  (QPM) 

•  Requirements  Development  (RD) 

•  Requirements  Management  (REQM) 

•  Risk  Management  (RSKM) 

•  Supplier  Agreement  Management  (SAM) 

•  Technical  Solution  (TS) 

•  Validation  (VAL) 

•  Verification  (VER) 


6  This  process  area  has  "+IPPD"  after  its  name  because  it  contains  a  goal  and  practices  that  are  specific  to  IPPD. 
The  material  specific  to  IPPD  is  called  an  "IPPD  addition."  All  process  areas  with  IPPD  additions  have 
"+IPPD"  after  their  name. 
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Purpose  Statements 


The  purpose  statement  describes  the  purpose  of  the  process  area  and 
is  an  informative  component. 

For  example,  the  purpose  statement  of  the  Organizational  Process 
Definition  process  area  is  “The  purpose  of  Organizational  Process 
Definition  (OPD)  is  to  establish  and  maintain  a  usable  set  of 
organizational  process  assets  and  work  environment  standards.” 

Introductory  Notes 


The  introductory  notes  section  of  the  process  area  describes  the  major 
concepts  covered  in  the  process  area  and  is  an  informative  component. 

An  example  from  the  introductory  notes  of  the  Project  Planning  process 
area  is  “Planning  begins  with  requirements  that  define  the  product  and 
project.” 

Related  Process  Areas 


The  related  process  areas  section  lists  references  to  related  process 
areas  and  reflects  the  high-level  relationships  among  the  process 
areas.  The  related  process  area  section  is  an  informative  component. 

An  example  of  a  reference  found  in  the  related  process  areas  section  of 
the  Project  Planning  process  area  is  “Refer  to  the  Risk  Management 
process  area  for  more  information  about  identifying  and  managing 
risks.” 

Specific  Goals 


A  specific  goal  describes  the  unique  characteristics  that  must  be 
present  to  satisfy  the  process  area.  A  specific  goal  is  a  required  model 
component  and  is  used  in  appraisals  to  help  determine  whether  a 
process  area  is  satisfied. 

For  example,  a  specific  goal  from  the  Configuration  Management 
process  area  is  “Integrity  of  baselines  is  established  and  maintained.” 

Only  the  statement  of  the  specific  goal  is  a  required  model  component. 
The  title  of  a  specific  goal  (preceded  by  the  goal  number)  and  any  notes 
associated  with  the  goal  are  considered  informative  model  components. 

Generic  Goals 


Generic  goals  are  called  “generic”  because  the  same  goal  statement 
applies  to  multiple  process  areas.  A  generic  goal  describes  the 
characteristics  that  must  be  present  to  institutionalize  the  processes 
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that  implement  a  process  area.  A  generic  goal  is  a  required  model 
component  and  is  used  in  appraisals  to  determine  whether  a  process 
area  is  satisfied.  (See  the  Generic  Goals  and  Generic  Practices  section 
on  page  75  for  a  more  detailed  description  of  generic  goals.) 

An  example  of  a  generic  goal  is  “The  process  is  institutionalized  as  a 
defined  process.” 

Only  the  statement  of  the  generic  goal  is  a  required  model  component. 
The  title  of  a  generic  goal  (preceded  by  the  goal  number)  and  any  notes 
associated  with  the  goal  are  considered  informative  model  components. 

Specific  Goal  and  Practice  Summaries 


The  specific  goal  and  practice  summary  provides  a  high-level  summary 
of  the  specific  goals,  which  are  required  components,  and  the  specific 
practices,  which  are  expected  components.  The  specific  goal  and 
practice  summary  is  an  informative  component. 

Specific  Practices 


A  specific  practice  is  the  description  of  an  activity  that  is  considered 
important  in  achieving  the  associated  specific  goal.  The  specific 
practices  describe  the  activities  that  are  expected  to  result  in 
achievement  of  the  specific  goals  of  a  process  area.  A  specific  practice 
is  an  expected  model  component. 

For  example,  a  specific  practice  from  the  Project  Monitoring  and  Control 
process  area  is  “Monitor  commitments  against  those  identified  in  the 
project  plan.” 

Only  the  statement  of  the  specific  practice  is  an  expected  model 
component.  The  title  of  a  specific  practice  (preceded  by  the  practice 
number)  and  any  notes  associated  with  the  specific  practice  are 
considered  informative  model  components. 

Typical  Work  Products 


The  typical  work  products  section  lists  sample  output  from  a  specific 
practice.  These  examples  are  called  typical  work  products  because 
there  are  often  other  work  products  that  are  just  as  effective  but  are  not 
listed.  A  typical  work  product  is  an  informative  model  component. 

For  example,  a  typical  work  product  for  the  specific  practice  “Monitor 
the  actual  values  of  the  project  planning  parameters  against  the  project” 
in  the  Project  Monitoring  and  Control  process  area  is  “Records  of 
significant  deviations.” 
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Subpractices 


A  subpractice  is  a  detailed  description  that  provides  guidance  for 
interpreting  and  implementing  a  specific  or  generic  practice. 
Subpractices  may  be  worded  as  if  prescriptive,  but  are  actually  an 
informative  component  meant  only  to  provide  ideas  that  may  be  useful 
for  process  improvement. 

For  example,  a  subpractice  for  the  specific  practice  “Take  corrective 
action  on  identified  issues”  in  the  Project  Monitoring  and  Control 
process  area  is  “Determine  and  document  the  appropriate  actions 
needed  to  address  the  identified  issues.” 

Generic  Practices 


Generic  practices  are  called  “generic”  because  the  same  practice 
applies  to  multiple  process  areas.  A  generic  practice  is  the  description 
of  an  activity  that  is  considered  important  in  achieving  the  associated 
generic  goal.  A  generic  practice  is  an  expected  model  component. 

For  example,  a  generic  practice  for  the  generic  goal  “The  process  is 
institutionalized  as  a  managed  process”  is  “Provide  adequate  resources 
for  performing  the  process,  developing  the  work  products,  and  providing 
the  services  of  the  process.” 

Only  the  statement  of  the  generic  practice  is  an  expected  model 
component.  The  title  of  a  generic  practice  (preceded  by  the  practice 
number)  and  any  notes  associated  with  the  practice  are  considered 
informative  model  components. 

To  reduce  the  repetitiveness  of  this  information  and  to  conserve  the 
number  of  pages  required  to  present  this  information,  only  the  generic 
practice  title,  statement,  and  elaborations  appear  in  the  process  areas. 
(See  the  Generic  Goals  and  Generic  Practices  section  on  page  75  for  a 
complete  description  of  the  generic  practices.) 

Generic  Practice  Elaborations 


A  generic  practice  elaboration  appears  after  a  generic  practice  in  a 
process  area  to  provide  guidance  on  how  the  generic  practice  should 
be  applied  uniquely  to  the  process  area.  A  generic  practice  elaboration 
is  an  informative  model  component. 

For  example,  a  generic  practice  elaboration  after  the  generic  practice 
“Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  project  planning  process”  in  the  Project  Planning 
process  area  is  “This  policy  establishes  organizational  expectations  for 
estimating  the  planning  parameters,  making  internal  and  external 
commitments,  and  developing  the  plan  for  managing  the  project.” 
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Supporting  Informative  Components 


In  many  places,  further  information  is  needed  to  describe  a  concept. 
This  informative  material  is  provided  in  the  form  of  the  following 
components: 

•  Notes 

•  Examples 

•  Amplifications 

•  References 

Notes 


A  note  is  text  that  can  accompany  nearly  any  other  model  component.  It 
may  provide  detail,  background,  or  rationale.  A  note  is  an  informative 
model  component. 

For  example,  a  note  that  accompanies  the  specific  practice  “Implement 
the  selected  action  proposals  that  were  developed  in  causal  analysis”  in 
the  Causal  Analysis  and  Resolution  process  area  is  “Only  changes  that 
prove  to  be  of  value  should  be  considered  for  broad  implementation.” 

Examples 


An  example  is  a  component  comprising  text  and  often  a  list  of  items, 
usually  in  a  box,  that  can  accompany  nearly  any  other  component  and 
provides  one  or  more  examples  to  clarify  a  concept  or  described 
activity.  An  example  is  an  informative  model  component. 

The  following  is  an  example  that  accompanies  the  subpractice 
“Document  noncompliance  issues  when  they  cannot  be  resolved  within 
the  project”  under  the  specific  practice  “Communicate  quality  issues 
and  ensure  resolution  of  noncompliance  issues  with  the  staff  and 
managers”  in  the  Process  and  Product  Quality  Assurance  process  area. 


Examples  of  ways  to  resolve  noncompliance  within  the  project  include  the  following: 

•  Fixing  the  noncompliance 

•  Changing  the  process  descriptions,  standards,  or  procedures  that  were  violated 

•  Obtaining  a  waiver  to  cover  the  noncompliance  issue 


Amplifications 


An  amplification  is  a  note  or  example  that  is  relevant  to  a  particular 
discipline.  The  disciplines  covered  in  this  model  are  hardware 
engineering,  systems  engineering,  and  software  engineering. 
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Each  amplification  is  labeled  with  a  heading  that  indicates  the  discipline 
to  which  it  applies.  For  example,  an  amplification  for  software 
engineering  is  labeled  “For  Software  Engineering.”  An  amplification  is 
an  informative  model  component. 

An  example  of  an  amplification  is  the  one  that  accompanies  the  specific 
practice  “Establish  and  maintain  the  overall  project  plan  content”  in  the 
Project  Planning  process  area.  The  amplification  states  “For  Hardware 
Engineering:  For  hardware,  the  planning  document  is  often  referred  to 
as  a  hardware  development  plan.  Development  activities  in  preparation 
for  production  may  be  included  in  the  hardware  development  plan  or 
defined  in  a  separate  production  plan.” 

References 


A  reference  is  a  pointer  to  additional  or  more  detailed  information  in 
related  process  areas  and  can  accompany  nearly  any  other  model 
component.  A  reference  is  an  informative  model  component. 

For  example,  a  reference  that  accompanies  the  specific  practice  “Select 
the  subprocesses  that  compose  the  project's  defined  process  based  on 
historical  stability  and  capability  data”  in  the  Quantitative  Project 
Management  process  area  is  “Refer  to  the  Organizational  Process 
Definition  process  area  for  more  information  about  the  organization's 
process  asset  library,  which  might  include  a  process  element  of  known 
and  needed  capability.” 


Numbering  Scheme 


Specific  and  generic  goals  are  numbered  sequentially.  Each  specific 
goal  begins  with  the  prefix  SG  (e.g.,  SG  1).  Each  generic  goal  begins 
with  the  prefix  GG  (e.g.,  GG  2). 

Each  specific  practice  begins  with  the  prefix  SP,  followed  by  a  number 
in  the  form  x.y  (e.g.,  SP  1.1).  The  x  is  the  same  number  as  the  goal  to 
which  the  specific  practice  maps.  The  y  is  the  sequence  number  of  the 
specific  practice  under  the  specific  goal. 

An  example  of  specific  practice  numbering  is  in  the  Project  Planning 
process  area.  The  first  specific  practice  is  numbered  SP  1.1  and  the 
second  is  SP  1 .2. 
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Each  generic  practice  begins  with  the  prefix  GP,  followed  by  a  number 
in  the  form  x.y  (e.g.,  GP  1.1). 

The  x  corresponds  to  the  number  of  the  generic  goal.  The  y  is  the 
sequence  number  of  the  generic  practice  under  the  generic  goal.  For 
example,  the  first  generic  practice  associated  with  GG  2  is  numbered 
GP  2.1  and  the  second  is  GP  2.2. 


Typographical  Conventions 


The  typographical  conventions  used  in  this  model  were  designed  to 
enable  you  to  select  what  you  need  and  use  it  effectively.  We  present 
model  components  in  formats  that  allow  you  to  find  them  quickly  on  the 
page. 

Figures  2.2  through  2.4  are  sample  pages  from  process  areas  in  Part 
Two;  they  show  the  different  process  area  components,  labeled  so  that 
you  can  identify  them.  Notice  that  components  differ  typographically  so 
that  you  can  easily  identify  each  one. 
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specific  goal  and 

CVWvarinormr'  1  " 

practice  summary 

Specific  Coal  and 

CG  l  Determine  Caues  of  Defeck 

CP  l.l  Oeled  Defect  Data  to  *ndyjb 
CP  12  fnalyae  Cannes 
CG2.*ddreis  Caum  of  Defect! 

CP  2.1  tnplemenl  he  AclonPrcpoidi 
CP  22  equate  lie  Bfec I  ofChanget 
CP  23  Peccrt  Data 


Specific  Practices  by  Goal _ 

specific  goal 

SG  1 _ Determine  Causes  of  Defects _ 

Root  causes  of  defects  and  other  problems  are  systematically  deter  min 

A  root  cause  is  a  source  of  a  defect  such  that  if  it  is  removed, the  defect 
is  decreased  or  removed. 


SP  1.1 


typical  work 
product  — 


Select  Defect  Data  for  Analysis _ 

Select  the  defects  and  other  problems  for  analysis. 


specific  practice 


Typical  Work  Products 

fe  1 .  Defect  and  problem  data  selected  for  futher  anat/sfe 

subpractice 

Subpractices 

1 .  Gather  relevant  defect  or  problem 


Examples  of  relent  ctefectdata  may  include  the  folbtAing: 

•  Defects  reported  by  the  customer 

•  Defects  reported  by  end  user 

•  Defects  found  h  peer  retiews 

•  Defects  found  h  testing 


Examples  of  relevant  problem  data  may  include  the  follouxing: 

•  Project  management  prcblem  reports  retiring  corrective  action 

•  Process  capability  problems 

•  Process  duration  measurements 

•  Earned  value  measurements  by  process  (e.gv  cost  performance  index) 

•  Resotrce  throucjiput  utilizaticn,  or  response  time  measurements 


reference 


Refer  to  the  Verification  process  area  for  more  information  aria 
work  product  verification. 


Causal  Analysis  and  Resolution  (CAR) 


Figure  2.2:  Sample  Page  from  CAR 
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For  Software  Engineering 

Examples  ofveriric^riort  methods  include  tfe  folfo'drg: 

•  Path  coverage  tesrirg 

•  Load,  stress  and  performance  testing 

•  Dedsion-table-basedtes^ng 

•  Functional  ckwmposrihn-bassd  testing 

•  Teshcase reuse 

•  Acceptance  tests 


For  Systems  Engineering 

Veriticairon  forsydems  engineering  typically  includes  prototyping . 
«0<feJlrffg,  a7of  simulation  to  verify  adequacy  of  system  design  find' 
allocation). 


For  Hardware  Engineering 

Verification  forhardware  engineering  typically  requires  a  parametric 
approach  that  considers  various  environmental  conditions  ^g..  pressure, 
temperature,  vibration,  humidity),  various  input  ranges  $a.g.,  input  power 
could  be  rated  at  20V  to  32  V  for  a  planned  nominal  of  28V).  variations 
induoed  from  part  to  part  tolerance  issues,  and  many  other  variables. 
Hardware  verification  normally  teds  most  variables  separately  except  when 
problematic  interactions  are  suspected. 


amplifications 


note 


Selection  of  the  verificilon  methods  typically  begins  with  involvement  in 
the  definition  of  product  and  product  component  requirements  to  ensue 
that  these  requirements  are  verifiable.  Reverification  should  be  Jk 
addressed  by  the  verification  methods  to  ensure  that  rework  performed 
on  work  products  does  not  cause  unintended  defects.  Suppliers  should 
be  involved  in  the  selection  to  ensure  that  the  project's  methods  are 
appropriate  for  the  supplier's  envronment. 


IPPD  Addition 

The  verification  methods  should  be  developed  concurrently  and  iteratively 
with  the  product  and  product  component  designs. _ 


typical  work 
products 


subpractice 


Typical  Work  Products 

1 .  Lists  of  wk  products  selected  for  verification 

2 .  Verification  methods  f cr  each  selected  work  product 


Subpractices 

1 .  Identify  work  products  f cr  verification . 


Verification  (VER) 
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Figure  2.3:  Sample  Page  from  VER 
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continuous  only  box 


UP  2.1 _ Establish  an  Organizational  Pd  icy 


staged  only  box 


£ stab  fish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  integrated  project  management  process. 


Elaboration: 


GP  elaboration 


This  policy  establishes  organizational  expectations  fcr  establishing  and 
maintaining  the  projects  defined  process  from  project  startup  through 
the  life  of  the  project,  using  the  project's  defined  process  in  managing 
the  project,  and  coordin^ing  and  collaborating  with  relevant 
stakeholders. 


addition 


IPPD  Addition 

This  policy  also  establishes  organizational  expectations  for  applying  IPPD 
principles. _ 


170 


Integrated  Project  Management  -HPPD(IPM+IPPD) 


Figure  2.4:  Sample  Page  from  IPM+IPPD 


Representation-Specific  Content 


In  Part  Two,  you  will  notice  that  some  components  in  the  Generic 
Practices  by  Goal  section  of  each  process  area  are  in  a  box  and  labeled 
“Staged  Only,”  “Continuous  Only,”  or  “Continuous/Maturity  Levels  3-5.” 

Components  that  are  not  marked  apply  to  both  representations. 
Components  marked  “Staged  Only”  apply  only  if  you  are  using  the 
staged  representation.  Components  marked  “Continuous  Only”  apply 
only  if  you  are  using  the  continuous  representation.  (See  Figure  2.4  for 
an  example.) 
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Components  marked  “Continuous/Maturity  Levels  3-5”  apply  if  you  are 
using  the  continuous  representation  or  if  you  are  using  the  staged 
representation  and  are  pursuing  maturity  level  3,  4,  or  5.  However, 
these  components  do  not  apply  if  you  are  pursuing  a  maturity  level  2 
rating  using  the  staged  representation. 

Additions 


An  addition  can  be  informative  material,  a  specific  practice,  a  specific 
goal,  or  a  process  area  that  extends  the  scope  of  a  model  or 
emphasizes  a  particular  aspect  of  its  use.  In  this  document,  all  additions 
apply  to  IPPD. 

An  example  of  an  addition  is  the  one  from  the  Organizational  Training 
process  area  that  appears  after  specific  goal  1 ,  “Establish  an 
Organizational  Training  Capability.”  The  addition  states  “Cross¬ 
functional  training,  leadership  training,  interpersonal  skills  training,  and 
training  in  the  skills  needed  to  integrate  appropriate  business  and 
technical  functions  is  needed  by  integrated  team  members.  The 
potentially  wider  range  of  requirements  and  participant  backgrounds 
may  require  relevant  stakeholders  who  were  not  involved  in 
requirements  development  to  take  cross  training  in  the  disciplines 
involved  in  product  design  in  order  to  commit  to  requirements  with  a  full 
understanding  of  the  range  of  requirements  and  their  interrelationships.” 
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3  Tying  It  All  Together 


Now  that  you  have  been  introduced  to  the  components  of  CMMI 
models,  you  need  to  understand  how  they  all  fit  together  to  meet  your 
process  improvement  needs  [Dymond  2004].  In  this  chapter,  we 
introduce  the  concept  of  levels  and  show  how  the  process  areas  are 
organized  and  used.  To  do  this,  we  need  to  revisit  the  discussion  that 
began  in  Chapter  1 . 


Understanding  Levels 


Levels  are  used  in  CMMI  to  describe  an  evolutionary  path 
recommended  for  an  organization  that  wants  to  improve  the  processes 
it  uses  to  develop  and  maintain  its  products  and  services.  Levels  can 
also  be  the  outcome  of  the  rating  activity  of  appraisals.7  Appraisals  can 
be  performed  for  organizations  that  comprise  entire  (usually  small) 
companies,  or  for  smaller  groups  such  as  a  group  of  projects  or  a 
division  within  a  company. 

CMMI  supports  two  improvement  paths.  One  path  enables 
organizations  to  incrementally  improve  processes  corresponding  to  an 
individual  process  area  (or  process  areas)  selected  by  the  organization. 
The  other  path  enables  organizations  to  improve  a  set  of  related 
processes  by  incrementally  addressing  successive  sets  of  process 
areas. 

These  two  improvement  paths  are  associated  with  the  two  types  of 
levels  that  correspond  to  the  two  representations  discussed  in  Chapter 
1 .  For  the  continuous  representation,  we  use  the  term  “capability  level.” 
For  the  staged  representation,  we  use  the  term  “maturity  level.” 

Regardless  of  which  representation  you  select,  the  concept  of  levels  is 
the  same.  Levels  characterize  improvement  from  an  ill-defined  state  to 
a  state  that  uses  quantitative  information  to  determine  and  manage 
improvements  that  are  needed  to  meet  an  organization’s  business 
objectives. 

To  reach  a  particular  level,  an  organization  must  satisfy  all  of  the 
appropriate  goals  of  the  process  area  or  set  of  process  areas  that  are 


7  For  more  information  about  appraisals,  refer  to  Appraisal  Requirements  for  CMMI  and  the  Standard  CMMI 
Appraisal  Method  for  Process  Improvement  Method  Definition  Document  [SEI  2006a,  SEI  2006b]. 
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targeted  for  improvement,  regardless  of  whether  it  is  a  capability  or  a 
maturity  level. 

Both  representations  also  provide  ways  to  implement  process 
improvement  to  achieve  business  objectives.  Both  representations 
provide  the  same  essential  content  and  use  the  same  model 
components. 


Structures  of  the  Continuous  and  Staged  Representations 


Figure  3.1  illustrates  the  structures  of  the  continuous  and  staged 
representations.  The  differences  jump  out  at  you  immediately  when  you 
look  at  the  structure  of  both  representations.  The  staged  representation 
utilizes  maturity  levels,  whereas  the  continuous  representation  utilizes 
capability  levels. 


Continuous  Representation 


Staged  Representation 


Figure  3.1:  Structure  of  the  Continuous  and  Staged  Representations 
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What  may  strike  you  as  you  compare  these  two  representations  is  their 
similarity.  Both  have  many  of  the  same  components  (e.g.,  process 
areas,  specific  goals,  and  specific  practices),  and  these  components 
have  the  same  hierarchy  and  configuration. 

What  is  not  readily  apparent  from  the  high-level  view  in  Figure  3.1  is 
that  the  continuous  representation  focuses  on  process  area  capability 
as  measured  by  capability  levels  and  the  staged  representation  focuses 
on  organizational  maturity  as  measured  by  maturity  levels.  These 
dimensions  (the  capability/maturity  dimensions)  of  CMMI  are  used  for 
benchmarking  and  appraisal  activities,  as  well  as  guiding  an 
organization’s  improvement  efforts. 

•  Capability  levels,  which  belong  to  a  continuous  representation, 
apply  to  an  organization’s  process  improvement  achievement  in 
individual  process  areas.  These  levels  are  a  means  for 
incrementally  improving  the  processes  corresponding  to  a  given 
process  area.  There  are  six  capability  levels,  numbered  0  through  5. 

•  Maturity  levels,  which  belong  to  a  staged  representation,  apply  to  an 
organization’s  process  improvement  achievement  across  multiple 
process  areas.  These  levels  are  a  means  of  predicting  the  general 
outcomes  of  the  next  project  undertaken.  There  are  five  maturity 
levels,  numbered  1  through  5. 

Table  3.1  compares  the  six  capability  levels  to  the  five  maturity  levels. 
Notice  that  the  names  of  four  of  the  levels  are  the  same  in  both 
representations.  The  differences  are  that  there  is  no  maturity  level  0  for 
the  staged  representation,  and  at  level  1 ,  the  capability  level  is 
Performed,  whereas  the  maturity  level  is  Initial.  Therefore,  the  starting 
point  is  different  for  the  two  representations. 


Table  3.1  Comparison  of  Capability  and  Maturity  Levels 


Level 

Continuous  Representation 
Capability  Levels 

Staged  Representation 

Maturity  Levels 

Level  0 

Incomplete 

N/A 

Level  1 

Performed 

Initial 

Level  2 

Managed 

Managed 

Level  3 

Defined 

Defined 

Level  4 

Quantitatively  Managed 

Quantitatively  Managed 

Level  5 

Optimizing 

Optimizing 
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The  continuous  representation  is  concerned  with  selecting  both  a 
particular  process  area  to  improve  and  the  desired  capability  level  for 
that  process  area.  In  this  context,  whether  a  process  is  performed  or 
incomplete  is  important.  Therefore,  the  name  “incomplete”  is  given  to 
the  continuous  representation  starting  point. 

Because  the  staged  representation  is  concerned  with  the  overall 
maturity  of  the  organization,  whether  individual  processes  are 
performed  or  incomplete  is  not  the  primary  focus.  Therefore,  the  name 
“initial”  is  given  to  the  staged  representation  starting  point. 

Both  capability  levels  and  maturity  levels  provide  a  way  to  measure  how 
well  organizations  can  and  do  improve  their  processes.  However,  the 
associated  approach  to  process  improvement  is  different. 


Understanding  Capability  Levels 


To  support  those  using  the  continuous  representation,  all  CMMI  models 
reflect  capability  levels  in  their  design  and  content.  A  capability  level 
consists  of  a  generic  goal  and  its  related  generic  practices  as  they 
relate  to  a  process  area,  which  can  improve  the  organization’s 
processes  associated  with  that  process  area.  As  you  satisfy  the  generic 
goal  and  its  generic  practices  at  each  capability  level,  you  reap  the 
benefits  of  process  improvement  for  that  process  area. 

The  six  capability  levels,  designated  by  the  numbers  0  through  5,  are  as 
follows: 

0.  Incomplete 

1 .  Performed 

2.  Managed 

3.  Defined 

4.  Quantitatively  Managed 

5.  Optimizing 


The  fact  that  capability  levels  2  through  5  use  the  same  terms  as 
generic  goals  2  through  5  is  intentional  because  each  of  these  generic 
goals  and  practices  reflects  the  meaning  of  the  capability  levels  in  terms 
of  goals  and  practices  you  can  implement.  (See  the  Generic  Goals  and 
Generic  Practices  section  on  page  75  for  more  information  about 
generic  goals  and  practices.)  A  short  description  of  each  capability  level 
follows. 


32 


Tying  It  All  Together 


CMMI  for  Development 
Version  1.2 

Capability  Level  0:  Incomplete 


An  “incomplete  process”  is  a  process  that  either  is  not  performed  or 
partially  performed.  One  or  more  of  the  specific  goals  of  the  process 
area  are  not  satisfied,  and  no  generic  goals  exist  for  this  level  since 
there  is  no  reason  to  institutionalize  a  partially  performed  process. 

Capability  Level  1 :  Performed 


A  capability  level  1  process  is  characterized  as  a  “performed  process.” 

A  performed  process  is  a  process  that  satisfies  the  specific  goals  of  the 
process  area.  It  supports  and  enables  the  work  needed  to  produce  work 
products. 

Although  capability  level  1  results  in  important  improvements,  those 
improvements  can  be  lost  overtime  if  they  are  not  institutionalized.  The 
application  of  institutionalization  (the  CMMI  generic  practices  at 
capability  levels  2  through  5)  helps  to  ensure  that  improvements  are 
maintained. 

Capability  Level  2:  Managed 


A  capability  level  2  process  is  characterized  as  a  “managed  process.”  A 
managed  process  is  a  performed  (capability  level  1)  process  that  has 
the  basic  infrastructure  in  place  to  support  the  process.  It  is  planned 
and  executed  in  accordance  with  policy;  employs  skilled  people  who 
have  adequate  resources  to  produce  controlled  outputs;  involves 
relevant  stakeholders;  is  monitored,  controlled,  and  reviewed;  and  is 
evaluated  for  adherence  to  its  process  description.  The  process 
discipline  reflected  by  capability  level  2  helps  to  ensure  that  existing 
practices  are  retained  during  times  of  stress. 

Capability  Level  3:  Defined 


A  capability  level  3  process  is  characterized  as  a  “defined  process.”  A 
defined  process  is  a  managed  (capability  level  2)  process  that  is 
tailored  from  the  organization’s  set  of  standard  processes  according  to 
the  organization’s  tailoring  guidelines,  and  contributes  work  products, 
measures,  and  other  process  improvement  information  to  the 
organizational  process  assets. 

A  critical  distinction  between  capability  levels  2  and  3  is  the  scope  of 
standards,  process  descriptions,  and  procedures.  At  capability  level  2, 
the  standards,  process  descriptions,  and  procedures  may  be  quite 
different  in  each  specific  instance  of  the  process  (e.g.,  on  a  particular 
project).  At  capability  level  3,  the  standards,  process  descriptions,  and 
procedures  for  a  project  are  tailored  from  the  organization’s  set  of 
standard  processes  to  suit  a  particular  project  or  organizational  unit  and 
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therefore  are  more  consistent,  except  for  the  differences  allowed  by  the 
tailoring  guidelines. 

Another  critical  distinction  is  that  at  capability  level  3,  processes  are 
typically  described  more  rigorously  than  at  capability  level  2.  A  defined 
process  clearly  states  the  purpose,  inputs,  entry  criteria,  activities,  roles, 
measures,  verification  steps,  outputs,  and  exit  criteria.  At  capability  level 
3,  processes  are  managed  more  proactively  using  an  understanding  of 
the  interrelationships  of  the  process  activities  and  detailed  measures  of 
the  process,  its  work  products,  and  its  services. 

Capability  Level  4:  Quantitatively  Managed 


A  capability  level  4  process  is  characterized  as  a  “quantitatively 
managed  process.”  A  quantitatively  managed  process  is  a  defined 
(capability  level  3)  process  that  is  controlled  using  statistical  and  other 
quantitative  techniques.  Quantitative  objectives  for  quality  and  process 
performance  are  established  and  used  as  criteria  in  managing  the 
process.  Quality  and  process  performance  is  understood  in  statistical 
terms  and  is  managed  throughout  the  life  of  the  process. 

Capability  Level  5:  Optimizing 


A  capability  level  5  process  is  characterized  as  an  “optimizing  process.” 
An  optimizing  process  is  a  quantitatively  managed  (capability  level  4) 
process  that  is  improved  based  on  an  understanding  of  the  common 
causes  of  variation  inherent  in  the  process.  The  focus  of  an  optimizing 
process  is  on  continually  improving  the  range  of  process  performance 
through  both  incremental  and  innovative  improvements. 

Remember  that  capability  levels  2  through  5  use  the  same  terms  as 
generic  goals  2  through  5,  and  a  detailed  description  of  these  terms 
appears  in  the  Generic  Goals  and  Generic  Practices  section  on  page 
75. 

Advancing  through  Capability  Levels 


The  capability  levels  of  a  process  area  are  achieved  through  the 
application  of  generic  practices  or  suitable  alternatives  to  the  processes 
associated  with  that  process  area. 

Reaching  capability  level  1  for  a  process  area  is  equivalent  to  saying 
that  the  processes  associated  with  that  process  area  are  “performed 
processes.” 

Reaching  capability  level  2  for  a  process  area  is  equivalent  to  saying 
that  there  is  a  policy  that  indicates  you  will  perform  the  process.  There 
is  a  plan  for  performing  it,  resources  are  provided,  responsibilities  are 
assigned,  training  to  perform  it  is  provided,  selected  work  products 
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related  to  performing  the  process  are  controlled,  and  so  on.  In  other 
words,  a  capability  level  2  process  can  be  planned  and  monitored  just 
like  any  project  or  support  activity. 

Reaching  capability  level  3  for  a  process  area  assumes  that  an 
organizational  standard  process  exists  associated  with  that  process 
area,  which  can  be  tailored  to  the  needs  of  the  project.  The  processes 
in  the  organization  are  now  more  consistently  defined  and  applied 
because  they  are  based  on  organizational  standard  processes. 

Reaching  capability  level  4  for  a  process  area  assumes  that  this 
process  area  is  a  key  business  driver  that  the  organization  wants  to 
manage  using  quantitative  and  statistical  techniques.  This  analysis 
gives  the  organization  more  visibility  into  the  performance  of  selected 
subprocesses  that  will  make  it  more  competitive  in  the  marketplace. 

Reaching  capability  level  5  for  a  process  area  assumes  that  you  have 
stabilized  the  selected  subprocesses  and  that  you  want  to  reduce  the 
common  causes  of  variation  within  that  process.  Remember  that 
variation  is  a  natural  occurrence  in  any  process,  so  although  it  is 
conceptually  feasible  to  improve  all  processes,  it  would  not  be 
economical  to  improve  all  processes  to  level  5.  Again,  you  would 
concentrate  on  those  processes  that  would  help  you  to  meet  your 
business  objectives. 


Understanding  Maturity  Levels 


To  support  those  using  the  staged  representation,  all  CMMI  models 
reflect  maturity  levels  in  their  design  and  content.  A  maturity  level 
consists  of  related  specific  and  generic  practices  for  a  predefined  set  of 
process  areas  that  improve  the  organization’s  overall  performance.  The 
maturity  level  of  an  organization  provides  a  way  to  predict  an 
organization’s  performance  in  a  given  discipline  or  set  of  disciplines. 
Experience  has  shown  that  organizations  do  their  best  when  they  focus 
their  process  improvement  efforts  on  a  manageable  number  of  process 
areas  at  a  time  and  that  those  areas  require  increasing  sophistication 
as  the  organization  improves. 

A  maturity  level  is  a  defined  evolutionary  plateau  for  organizational 
process  improvement.  Each  maturity  level  matures  an  important  subset 
of  the  organization’s  processes,  preparing  it  to  move  to  the  next 
maturity  level.  The  maturity  levels  are  measured  by  the  achievement  of 
the  specific  and  generic  goals  associated  with  each  predefined  set  of 
process  areas. 
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There  are  five  maturity  levels,  each  a  layer  in  the  foundation  for  ongoing 
process  improvement,  designated  by  the  numbers  1  through  5: 

1.  Initial 

2.  Managed 

3.  Defined 

4.  Quantitatively  Managed 

5.  Optimizing 


Remember  that  maturity  levels  2  through  5  use  the  same  terms  as 
capability  levels  2  through  5.  This  was  intentional  because  the  concepts 
of  maturity  levels  and  capability  levels  are  complementary.  Maturity 
levels  are  used  to  characterize  organizational  improvement  relative  to  a 
set  of  process  areas,  and  capability  levels  characterize  organizational 
improvement  relative  to  an  individual  process  area. 

Maturity  Level  1:  Initial 


At  maturity  level  1 ,  processes  are  usually  ad  hoc  and  chaotic.  The 
organization  usually  does  not  provide  a  stable  environment  to  support 
the  processes.  Success  in  these  organizations  depends  on  the 
competence  and  heroics  of  the  people  in  the  organization  and  not  on 
the  use  of  proven  processes.  In  spite  of  this  chaos,  maturity  level  1 
organizations  often  produce  products  and  services  that  work;  however, 
they  frequently  exceed  their  budgets  and  do  not  meet  their  schedules. 

Maturity  level  1  organizations  are  characterized  by  a  tendency  to  over 
commit,  abandonment  of  processes  in  a  time  of  crisis,  and  an  inability 
to  repeat  their  successes. 

Maturity  Level  2:  Managed 


At  maturity  level  2,  the  projects  of  the  organization  have  ensured  that 
processes  are  planned  and  executed  in  accordance  with  policy;  the 
projects  employ  skilled  people  who  have  adequate  resources  to 
produce  controlled  outputs;  involve  relevant  stakeholders;  are 
monitored,  controlled,  and  reviewed;  and  are  evaluated  for  adherence 
to  their  process  descriptions.  The  process  discipline  reflected  by 
maturity  level  2  helps  to  ensure  that  existing  practices  are  retained 
during  times  of  stress.  When  these  practices  are  in  place,  projects  are 
performed  and  managed  according  to  their  documented  plans. 

At  maturity  level  2,  the  status  of  the  work  products  and  the  delivery  of 
services  are  visible  to  management  at  defined  points  (e.g.,  at  major 
milestones  and  at  the  completion  of  major  tasks).  Commitments  are 
established  among  relevant  stakeholders  and  are  revised  as  needed. 
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Work  products  are  appropriately  controlled.  The  work  products  and 
services  satisfy  their  specified  process  descriptions,  standards,  and 
procedures. 

Maturity  Level  3:  Defined 


At  maturity  level  3,  processes  are  well  characterized  and  understood, 
and  are  described  in  standards,  procedures,  tools,  and  methods.  The 
organization’s  set  of  standard  processes,  which  is  the  basis  for  maturity 
level  3,  is  established  and  improved  overtime.  These  standard 
processes  are  used  to  establish  consistency  across  the  organization. 
Projects  establish  their  defined  processes  by  tailoring  the  organization’s 
set  of  standard  processes  according  to  tailoring  guidelines.  (See  the 
glossary  for  a  definition  of  “organization’s  set  of  standard  processes.”) 

A  critical  distinction  between  maturity  levels  2  and  3  is  the  scope  of 
standards,  process  descriptions,  and  procedures.  At  maturity  level  2, 
the  standards,  process  descriptions,  and  procedures  may  be  quite 
different  in  each  specific  instance  of  the  process  (e.g.,  on  a  particular 
project).  At  maturity  level  3,  the  standards,  process  descriptions,  and 
procedures  for  a  project  are  tailored  from  the  organization’s  set  of 
standard  processes  to  suit  a  particular  project  or  organizational  unit  and 
therefore  are  more  consistent,  except  for  the  differences  allowed  by  the 
tailoring  guidelines. 

Another  critical  distinction  is  that  at  maturity  level  3,  processes  are 
typically  described  more  rigorously  than  at  maturity  level  2.  A  defined 
process  clearly  states  the  purpose,  inputs,  entry  criteria,  activities,  roles, 
measures,  verification  steps,  outputs,  and  exit  criteria.  At  maturity  level 
3,  processes  are  managed  more  proactively  using  an  understanding  of 
the  interrelationships  of  the  process  activities  and  detailed  measures  of 
the  process,  its  work  products,  and  its  services. 

At  maturity  level  3,  the  organization  must  further  mature  the  maturity 
level  2  process  areas.  The  generic  practices  associated  with  generic 
goal  3  that  were  not  addressed  at  maturity  level  2  are  applied  to 
achieve  maturity  level  3. 

Maturity  Level  4:  Quantitatively  Managed 


At  maturity  level  4,  the  organization  and  projects  establish  quantitative 
objectives  for  quality  and  process  performance  and  use  them  as  criteria 
in  managing  processes.  Quantitative  objectives  are  based  on  the  needs 
of  the  customer,  end  users,  organization,  and  process  implementers. 
Quality  and  process  performance  is  understood  in  statistical  terms  and 
is  managed  throughout  the  life  of  the  processes  [SEI  2001], 
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For  selected  subprocesses,  detailed  measures  of  process  performance 
are  collected  and  statistically  analyzed.  Quality  and  process- 
performance  measures  are  incorporated  into  the  organization’s 
measurement  repository  to  support  fact-based  decision  making 
[McGarry  2000],  Special  causes  of  process  variation  are  identified  and, 
where  appropriate,  the  sources  of  special  causes  are  corrected  to 
prevent  future  occurrences.  (See  the  definition  of  “special  cause  of 
process  variation”  in  the  glossary.) 

A  critical  distinction  between  maturity  levels  3  and  4  is  the  predictability 
of  process  performance.  At  maturity  level  4,  the  performance  of 
processes  is  controlled  using  statistical  and  other  quantitative 
techniques,  and  is  quantitatively  predictable.  At  maturity  level  3, 
processes  are  typically  only  qualitatively  predictable. 

Maturity  Level  5:  Optimizing 


At  maturity  level  5,  an  organization  continually  improves  its  processes 
based  on  a  quantitative  understanding  of  the  common  causes  of 
variation  inherent  in  processes.  (See  the  definition  of  “common  cause  of 
process  variation”  in  the  glossary.) 

Maturity  level  5  focuses  on  continually  improving  process  performance 
through  incremental  and  innovative  process  and  technological 
improvements.  Quantitative  process  improvement  objectives  for  the 
organization  are  established,  continually  revised  to  reflect  changing 
business  objectives,  and  used  as  criteria  in  managing  process 
improvement.  The  effects  of  deployed  process  improvements  are 
measured  and  evaluated  against  the  quantitative  process  improvement 
objectives.  Both  the  defined  processes  and  the  organization’s  set  of 
standard  processes  are  targets  of  measurable  improvement  activities. 

A  critical  distinction  between  maturity  levels  4  and  5  is  the  type  of 
process  variation  addressed.  At  maturity  level  4,  the  organization  is 
concerned  with  addressing  special  causes  of  process  variation  and 
providing  statistical  predictability  of  the  results.  Although  processes  may 
produce  predictable  results,  the  results  may  be  insufficient  to  achieve 
the  established  objectives.  At  maturity  level  5,  the  organization  is 
concerned  with  addressing  common  causes  of  process  variation  and 
changing  the  process  (to  shift  the  mean  of  the  process  performance  or 
reduce  the  inherent  process  variation  experienced)  to  improve  process 
performance  and  to  achieve  the  established  quantitative  process 
improvement  objectives. 
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Advancing  through  Maturity  Levels 


Organizations  can  achieve  progressive  improvements  in  their 
organizational  maturity  by  achieving  control  first  at  the  project  level  and 
continuing  to  the  most  advanced  level — organization-wide  continuous 
process  improvement — using  both  quantitative  and  qualitative  data  to 
make  decisions. 

Since  improved  organizational  maturity  is  associated  with  improvement 
in  the  range  of  expected  results  that  can  be  achieved  by  an 
organization,  it  is  one  way  of  predicting  the  general  outcomes  of  the 
organization’s  next  project.  For  instance,  at  maturity  level  2,  the 
organization  has  been  elevated  from  ad  hoc  to  disciplined  by 
establishing  sound  project  management.  As  your  organization  achieves 
the  generic  and  specific  goals  for  the  set  of  process  areas  in  a  maturity 
level,  you  are  increasing  your  organizational  maturity  and  reaping  the 
benefits  of  process  improvement.  Because  each  maturity  level  forms  a 
necessary  foundation  for  the  next  level,  trying  to  skip  maturity  levels  is 
usually  counterproductive. 

At  the  same  time,  you  must  recognize  that  process  improvement  efforts 
should  focus  on  the  needs  of  the  organization  in  the  context  of  its 
business  environment  and  that  process  areas  at  higher  maturity  levels 
may  address  the  current  needs  of  an  organization  or  project.  For 
example,  organizations  seeking  to  move  from  maturity  level  1  to 
maturity  level  2  are  frequently  encouraged  to  establish  a  process  group, 
which  is  addressed  by  the  Organizational  Process  Focus  process  area 
that  resides  at  maturity  level  3.  Although  a  process  group  is  not  a 
necessary  characteristic  of  a  maturity  level  2  organization,  it  can  be  a 
useful  part  of  the  organization’s  approach  to  achieving  maturity  level  2. 

This  situation  is  sometimes  characterized  as  establishing  a  maturity 
level  1  process  group  to  bootstrap  the  maturity  level  1  organization  to 
maturity  level  2.  Maturity  level  1  process  improvement  activities  may 
depend  primarily  on  the  insight  and  competence  of  the  process  group 
staff  until  an  infrastructure  to  support  more  disciplined  and  widespread 
improvement  is  in  place. 

Organizations  can  institute  specific  process  improvements  at  any  time 
they  choose,  even  before  they  are  prepared  to  advance  to  the  maturity 
level  at  which  the  specific  practice  is  recommended.  In  such  situations, 
however,  organizations  should  understand  that  the  success  of  these 
improvements  is  at  risk  because  the  foundation  for  their  successful 
institutionalization  has  not  been  completed.  Processes  without  the 
proper  foundation  may  fail  at  the  very  point  they  are  needed  most — 
under  stress. 
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A  defined  process  that  is  characteristic  of  a  maturity  level  3  organization 
can  be  placed  at  great  risk  if  maturity  level  2  management  practices  are 
deficient.  For  example,  management  may  commit  to  a  poorly  planned 
schedule  or  fail  to  control  changes  to  baselined  requirements.  Similarly, 
many  organizations  prematurely  collect  the  detailed  data  characteristic 
of  maturity  level  4,  only  to  find  the  data  uninterpretable  because  of 
inconsistencies  in  processes  and  measurement  definitions. 

Another  example  of  using  processes  associated  with  higher  maturity- 
level  process  areas  is  in  the  building  of  products.  Certainly,  we  would 
expect  maturity  level  1  organizations  to  perform  requirements  analysis, 
design,  integration,  and  verification.  These  activities  are  not  described 
until  maturity  level  3,  however,  where  they  are  described  as  the 
coherent,  well-integrated  engineering  processes  that  complement  a 
maturing  project  management  capability,  put  in  place  so  that  the 
engineering  improvements  are  not  lost  by  an  ad  hoc  management 
process. 
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Process  Areas 


Process  areas  are  viewed  differently  in  the  two  representations.  Figure 
3.2  compares  views  of  how  process  areas  are  used  in  the  continuous 
representation  and  the  staged  representation. 


Continuous 

Target  Profile 


Targeted  Capability  Levels 

Staged 

Selected  Maturity  Level 


Maturity  Level  5 
Maturity  Level  4 


Maturity  Level  3 


=  Groups  of  process  areas  chosen  for  process  improvement  to  achieve  maturity  level  3 


Figure  3.2:  Process  Areas  in  Continuous  and  Staged  Representations 
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The  continuous  representation  enables  the  organization  to  choose  the 
focus  of  its  process  improvement  efforts  by  choosing  those  process 
areas,  or  sets  of  interrelated  process  areas,  that  best  benefit  the 
organization  and  its  business  objectives.  Although  there  are  some  limits 
on  what  an  organization  can  choose  because  of  the  dependencies 
among  process  areas,  the  organization  has  considerable  freedom  in  its 
selection. 

To  support  those  using  the  continuous  representation,  process  areas 
are  organized  into  four  categories:  Process  Management,  Project 
Management,  Engineering,  and  Support.  These  categories  emphasize 
the  relationships  that  exist  among  the  process  areas  and  are  discussed 
in  Chapter  4. 

Once  you  select  the  process  areas,  you  must  also  select  how  much  you 
would  like  to  mature  the  processes  associated  with  those  process  areas 
(i.e.,  select  the  appropriate  capability  level).  Capability  levels  and 
generic  goals  and  practices  support  the  improvement  of  processes 
associated  with  individual  process  areas.  For  example,  an  organization 
may  wish  to  strive  to  reach  capability  level  2  in  one  process  area  and 
capability  level  4  in  another.  As  the  organization  reaches  a  capability 
level,  it  sets  its  sights  on  the  next  capability  level  for  one  of  these  same 
process  areas  or  decides  to  widen  its  view  and  address  a  larger  number 
of  process  areas. 

This  selection  is  typically  described  through  a  target  profile.  A  target 
profile  defines  all  of  the  process  areas  to  be  addressed  and  the  targeted 
capability  level  for  each.  This  profile  then  governs  which  goals  and 
practices  the  organization  will  address  in  its  process  improvement 
efforts. 

Most  organizations  will,  at  minimum,  target  capability  level  1,  which 
requires  that  all  specific  goals  of  the  process  area  be  achieved. 

However,  organizations  that  target  capability  levels  higher  than  1  will 
concentrate  on  the  institutionalization  of  the  selected  processes  in  the 
organization  by  implementing  the  associated  generic  goals  and 
practices. 

Conversely,  you  will  see  that  the  staged  representation  encourages  you 
to  always  look  at  process  areas  in  the  context  of  the  maturity  level  to 
which  they  belong.  The  process  areas  are  organized  by  maturity  levels 
to  reinforce  this  concept. 
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The  staged  representation  provides  a  predetermined  path  of 
improvement  from  maturity  level  1  to  maturity  level  5  that  involves 
achieving  the  goals  of  the  process  areas  at  each  maturity  level.  To 
support  those  using  the  staged  representation,  process  areas  are 
grouped  by  maturity  level,  indicating  which  process  areas  to  implement 
to  achieve  each  maturity  level.  For  example,  at  maturity  level  2,  there  is 
a  set  of  process  areas  that  an  organization  would  use  to  guide  its 
process  improvement  until  it  could  achieve  all  the  goals  of  all  these 
process  areas.  Once  maturity  level  2  is  achieved  this  way,  the 
organization  focuses  its  efforts  on  maturity  level  3  process  areas,  and 
so  on.  The  generic  goals  that  apply  to  each  process  area  are  also 
predetermined.  Generic  goal  2  applies  to  maturity  level  2  and  generic 
goal  3  applies  to  maturity  levels  3  through  5. 

Table  3.2  provides  a  list  of  all  process  areas  and  their  associated 
categories  and  maturity  levels.  To  explain  how  the  components  of  the 
process  areas  are  viewed  in  each  representation,  we  must  discuss  how 
the  representations  address  specific  practices. 
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Table  3.2  Process  Areas  and  Their  Associated  Categories  and  Maturity 
Levels 


Process  Area 

Category 

Maturity  Level 

Causal  Analysis  and  Resolution 

Support 

5 

Configuration  Management 

Support 

2 

Decision  Analysis  and  Resolution 

Support 

3 

Integrated  Project  Management  +IPPD 

Project 

Management 

3 

Measurement  and  Analysis 

Support 

2 

Organizational  Innovation  and 
Deployment 

Process 

Management 

5 

Organizational  Process  Definition 
+IPPD 

Process 

Management 

3 

Organizational  Process  Focus 

Process 

Management 

3 

Organizational  Process  Performance 

Process 

Management 

4 

Organizational  Training 

Process 

Management 

3 

Product  Integration 

Engineering 

3 

Project  Monitoring  and  Control 

Project 

Management 

2 

Project  Planning 

Project 

Management 

2 

Process  and  Product  Quality  Assurance 

Support 

2 

Quantitative  Project  Management 

Project 

Management 

4 

Requirements  Development 

Engineering 

3 

Requirements  Management 

Engineering 

2 

Risk  Management 

Project 

Management 

3 

Supplier  Agreement  Management 

Project 

Management 

2 

Technical  Solution 

Engineering 

3 

Validation 

Engineering 

3 

Verification 

Engineering 

3 
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Generic  Goals  and  Practices 

Generic  goals  are  required  model  components  that  apply  to  all  process 
areas.  Figure  3.3  illustrates  the  generic  goals  and  practices.  All  of  the 
generic  goals  and  practices  are  used  in  the  continuous  representation. 
(See  the  Generic  Goals  and  Generic  Practices  section  on  page  75  for  a 
more  detailed  description  of  generic  goals  and  practices.)  The  capability 
level  you  are  targeting  for  your  improvement  effort  will  determine  which 
generic  goals  and  practices  you  will  apply  to  the  process  area  you  have 
selected. 


Generic  Goals  and  Practices 


Figure  3.3:  Generic  Goals  and  Generic  Practices 


In  the  staged  representation,  only  generic  goals  2  and  3  are  used,  as 
illustrated  by  the  generic  practices  highlighted  in  gray  in  Figure  3.3. 
When  you  try  to  reach  maturity  level  2,  you  use  the  process  areas  at 
maturity  level  2  as  well  as  generic  goal  2  and  its  generic  practices. 

Notice  that  generic  goals  4  and  5  and  their  associated  generic  practices 
are  not  used.  This  is  because  not  all  processes  will  be  “raised”  above 
(i.e.,  matured  beyond)  a  defined  process.  Only  select  processes  and 
subprocesses  will  be  quantitatively  managed  and  optimized,  and  which 
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processes  and  subprocesses  are  selected  is  addressed  by  the  process 
areas  at  maturity  levels  4  and  5. 

When  you  reach  maturity  levels  3,  4,  and  5,  you  use  the  process  areas 
at  the  appropriate  maturity  levels  as  well  as  all  of  those  at  the  lower 
maturity  levels.  In  addition,  generic  goal  3  and  its  associated  generic 
practices  (which  include  the  generic  practices  associated  with  generic 
goal  2)  are  applied  to  all  of  these  process  areas.  This  means  that  even 
though  you  have  already  achieved  a  maturity  level  2  rating,  to  achieve  a 
maturity  level  3  rating  you  must  return  to  the  maturity  level  2  process 
areas  and  apply  generic  goal  3  and  its  generic  practices  as  well. 


Representation  Comparison 


Table  3.3  summarizes  the  differences  between  the  two  representations. 


Table  3.3  Comparing  Continuous  and  Staged  Representations 


Continuous  Representation  Staged  Representation 


The  organization  selects  process 
areas  and  capability  levels  based 
on  its  process  improvement 
objectives. 

Improvement  is  measured  using 
capability  levels.  Capability  levels 

•  Measure  maturity  of  a  par¬ 
ticular  process  across  an 
organization. 

•  Range  from  0  through  5. 

Capability  level  profiles  are  used 
to  target  and  track  process 
improvement  performance. 

Equivalent  staging  allows  an 
organization  using  the  continuous 
approach  to  process  improvement 
to  derive  a  maturity  level  as  part 
of  an  appraisal. 


The  organization  selects  process 
areas  based  on  the  maturity 
levels. 


Improvement  is  measured  using 
maturity  levels.  Maturity  levels 

•  Measure  maturity  of  a  set 
of  processes  across  an  or¬ 
ganization. 

•  Range  from  1  through  5. 

Maturity  levels  are  used  to  target 
and  track  process  improvement 
performance. 

There  is  no  need  for  an 
equivalence  mechanism  back  to 
the  continuous  approach. 
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Equivalent  Staging 


Equivalent  staging  is  a  way  to  compare  results  from  using  the 
continuous  representation  to  those  of  the  staged  representation.  In 
essence,  if  you  measured  improvement  relative  to  selected  process 
areas  using  capability  levels  in  the  continuous  representation,  how 
would  you  compare  that  to  maturity  levels?  Is  this  possible? 

Up  to  this  point,  we  have  not  discussed  process  appraisals  in  much 
detail.  The  SCAMPIsm  method8  is  used  for  appraising  organizations 
using  CMMI,  and  one  result  of  an  appraisal  is  a  rating  [Ahern  2005],  If 
the  continuous  representation  is  used  for  an  appraisal,  the  rating  is  a 
capability  level  profile.  If  the  staged  representation  is  used  for  an 
appraisal,  the  rating  is  a  maturity  level  (e.g.,  maturity  level  3)  rating. 

A  capability  level  profile  is  a  list  of  process  areas  and  the  corresponding 
capability  level  achieved  for  each.  This  profile  enables  an  organization 
to  track  its  capability  level  by  process  area.  The  profile  is  an 
achievement  profile  when  it  represents  the  organization’s  actual 
progress  for  each  process  area.  Alternatively,  the  profile  is  a  target 
profile  when  it  represents  the  organization’s  planned  process 
improvement  objectives.  Figure  3.4  illustrates  both  a  target  profile  and 
an  achievement  profile.  The  gray  portion  of  each  bar  represents  what 
has  been  achieved.  The  unshaded  portion  represents  what  remains  to 
be  accomplished  to  meet  the  target  profile. 


Capability  Capability  Capability  Capability  Capability 

Level  1  Level  2  Level  3  Level  4  Level  5 


Figure  3.4:  An  Example  of  an  Achievement  Profile  and  a  Target  Profile 


s  The  SCAMPI  method  is  described  in  chapter  5. 
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An  achievement  profile,  when  compared  with  a  target  profile,  enables 
an  organization  to  plan  and  track  its  progress  for  each  selected  process 
area.  Maintaining  capability  level  profiles  is  advisable  when  using  the 
continuous  representation. 

Target  staging  is  a  sequence  of  target  profiles  that  describes  the  path  of 
process  improvement  to  be  followed  by  the  organization.  When  building 
target  profiles,  the  organization  should  pay  attention  to  the 
dependencies  between  generic  practices  and  process  areas.  If  a 
generic  practice  depends  on  a  certain  process  area,  either  to  carry  out 
the  generic  practice  or  to  provide  a  prerequisite  product,  the  generic 
practice  may  be  much  less  effective  when  the  process  area  is  not 
implemented.9 

Although  there  are  many  reasons  to  use  the  continuous  representation, 
the  ratings  provided  by  capability  level  profiles  are  limited  in  their  ability 
to  provide  organizations  with  a  way  to  generally  compare  themselves 
with  other  organizations.  Capability  level  profiles  could  be  used  if  each 
organization  selected  the  same  process  areas;  however,  maturity  levels 
have  been  used  to  compare  organizations  for  years  and  already  provide 
predefined  sets  of  process  areas. 

Because  of  this  situation,  equivalent  staging  was  created.  Equivalent 
staging  enables  an  organization  using  the  continuous  representation  for 
an  appraisal  to  convert  a  capability  level  profile  to  the  associated 
maturity  level  rating. 

The  most  effective  way  to  depict  equivalent  staging  is  to  provide  a 
sequence  of  target  profiles,  each  of  which  is  equivalent  to  a  maturity 
level  rating  of  the  staged  representation.  The  result  is  a  target  staging 
that  is  equivalent  to  the  maturity  levels  of  the  staged  representation. 


9  See  Table  6.2  on  page  95  in  the  Generic  Goals  and  Generic  Practices  section  for  more  information  about  the 
dependencies  between  generic  practices  and  process  areas. 
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Figure  3.5  shows  a  summary  of  the  target  profiles  that  must  be 
achieved  when  using  the  continuous  representation  to  be  equivalent  to 
maturity  levels  2  through  5.  Each  shaded  area  in  the  capability  level 
columns  represents  a  target  profile  that  is  equivalent  to  a  maturity  level. 


Name 

Abbr 

ML 

CL1  CL2 

CL3 

CL4  CL5 

Requirements  Management 

REQM 

2 

Project  Planning 

PP 

2 

Target 

Project  Monitoring  and  Control 

PMC 

2 

Profile  2 

Supplier  Agreement  Manage¬ 

SAM 

2 

ment 

Measurement  and  Analysis 

MA 

2 

Process  and  Product  Quality 

PPQA 

2 

Assurance 

Configuration  Management 

CM 

2 

Requirements  Development 

RD 

3 

Technical  Solution 

TS 

3 

Product  Integration 

PI 

3 

Verification 

VER 

3 

Validation 

VAL 

3 

Target 

Profile  3 

Organizational  Process  Focus 

OPF 

3 

Organizational  Process 

OPD 

3 

Definition  +IPPD 

+  IPPD 

Organizational  Training 

OT 

3 

Integrated  Project  Manage¬ 

IPM 

3 

ment  +IPPD 

+  IPPD 

Risk  Management 

RSKM 

3 

Decision  Analysis  and  Resolu¬ 

DAR 

3 

tion 

Organizational  Process  Per¬ 

OPP 

4 

formance 

Target 

Quantitative  Project  Manage¬ 

QPM 

4 

Profile  4 

ment 

Organizational  Innovation  and 

OID 

5 

Deployment 

Target 

Causal  Analysis  and  Resolu¬ 

CAR 

5 

Profile  5 

tion 

Figure  3.5:  Target  Profiles  and  Equivalent  Staging 
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The  following  rules  summarize  equivalent  staging: 

•  To  achieve  maturity  level  2,  all  process  areas  assigned  to  maturity 
level  2  must  achieve  capability  level  2  or  higher. 

•  To  achieve  maturity  level  3,  all  process  areas  assigned  to  maturity 
levels  2  and  3  must  achieve  capability  level  3  or  higher. 

•  To  achieve  maturity  level  4,  all  process  areas  assigned  to  maturity 
levels  2,  3,  and  4  must  achieve  capability  level  3  or  higher. 

•  To  achieve  maturity  level  5,  all  process  areas  must  achieve 
capability  level  3  or  higher. 

These  rules  and  the  table  for  equivalent  staging  are  complete;  however, 
you  may  ask  why  target  profiles  4  and  5  do  not  extend  into  the  CL4  and 
CL5  columns.  The  reason  is  that  the  maturity  level  4  process  areas 
describe  a  selection  of  the  subprocesses  to  be  stabilized  based,  in  part, 
on  the  quality  and  process-performance  objectives  of  the  organization 
and  projects.  Not  every  process  area  will  be  addressed  in  the  selection 
and  CMMI  does  not  presume  in  advance  which  process  areas  might  be 
addressed  in  the  selection. 

So,  the  achievement  of  capability  level  4  for  process  areas  cannot  be 
predetermined  because  the  choices  depend  on  the  selections  made  by 
the  organization  in  its  implementation  of  the  maturity  level  4  process 
areas.  Thus,  Figure  3.5  does  not  show  target  profile  4  extending  into 
the  CL4  column,  although  some  process  areas  will  have  achieved 
capability  level  4.  The  situation  for  maturity  level  5  and  target  profile  5  is 
similar. 

The  existence  of  equivalent  staging  should  not  discourage  users  of  the 
continuous  representation  from  establishing  target  profiles  that  extend 
above  capability  level  3.  Such  a  target  profile  would  be  determined  in 
part  by  the  selections  made  by  the  organization  to  meet  its  business 
objectives. 
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4  Relationships  Among  Process  Areas 


In  this  chapter,  we  describe  interactions  among  process  areas  to  help 
you  see  the  organization’s  view  of  process  improvement  and  which 
process  areas  build  on  the  implementation  of  other  process  areas. 
Relationships  among  process  areas  are  presented  in  two  dimensions. 

The  first  dimension  comprises  the  interactions  of  individual  process 
areas  that  show  how  information  and  artifacts  flow  from  one  process 
area  to  another.  Shown  by  the  multiple  figures  and  descriptions  in  this 
chapter,  these  interactions  help  you  see  a  larger  view  of  process 
improvement. 

The  second  dimension  comprises  the  interactions  of  groups  of  process 
areas.  Shown  by  the  classification  of  some  process  areas  as  Basic  and 
others  as  Advanced,  these  classifications  illustrate  that  the  Basic 
process  areas  should  be  implemented  before  the  Advanced  process 
areas  to  ensure  that  the  prerequisites  are  met  to  successfully 
implement  the  Advanced  process  areas. 

Successful  process  improvement  initiatives  must  be  driven  by  the 
business  objectives  of  the  organization.  For  example,  a  common 
business  objective  is  to  reduce  the  time  it  takes  to  get  a  product  to 
market.  The  process  improvement  objective  derived  from  that  might  be 
to  improve  the  project  management  processes  to  ensure  on-time 
delivery;  those  improvements  rely  on  best  practices  in  the  Project 
Planning  and  Project  Monitoring  and  Control  process  areas. 


Four  Categories  of  CMMI  Process  Areas 


Process  areas  can  be  grouped  into  four  categories: 

•  Process  Management 

•  Project  Management 

•  Engineering 

•  Support 

Although  we  are  grouping  process  areas  this  way  to  discuss  their 
interactions,  process  areas  often  interact  and  have  an  effect  on  one 
another  regardless  of  their  defined  group.  For  example,  the  Decision 
Analysis  and  Resolution  process  area  provides  specific  practices  to 


Relationships  Among  Process  Areas 


51 


CMMI  for  Development 
Version  1.2 


address  the  formal  evaluation  that  is  used  in  the  Technical  Solution 
process  area  for  selecting  a  technical  solution  from  alternative 
solutions.  Technical  Solution  is  an  Engineering  process  area  and 
Decision  Analysis  and  Resolution  is  a  Support  process  area. 

Being  aware  of  the  interactions  that  exist  among  CMMI  process  areas 
and  which  process  areas  are  Basic  and  Advanced  will  help  you  apply 
CMMI  in  a  useful  and  productive  way.  The  following  sections  describe 
the  interactions  of  process  areas  within  the  categories  and  only  briefly 
describe  the  interactions  among  process  areas  in  other  categories. 
Interactions  among  process  areas  that  belong  to  different  categories 
are  described  in  references  within  the  Related  Process  Areas  section  of 
the  process  areas  in  Part  Two.  Refer  to  Chapter  2  for  more  information 
about  references. 


Process  Management 


Process  Management  process  areas  contain  the  cross-project  activities 
related  to  defining,  planning,  deploying,  implementing,  monitoring, 
controlling,  appraising,  measuring,  and  improving  processes. 

The  Process  Management  process  areas  of  CMMI  are  as  follows: 

•  Organizational  Process  Focus 

•  Organizational  Process  Definition  +IPPD10 

•  Organizational  Training 

•  Organizational  Process  Performance 

•  Organizational  Innovation  and  Deployment 

Basic  Process  Management  Process  Areas 


The  Basic  Process  Management  process  areas  provide  the 
organization  with  a  capability  to  document  and  share  best  practices, 
organizational  process  assets,  and  learning  across  the  organization. 

Figure  4.1  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Basic  Process  Management  process  areas  and  with  other  process  area 
categories.  As  illustrated  in  Figure  4.1,  the  Organizational  Process 
Focus  process  area  helps  the  organization  to  plan,  implement,  and 
deploy  organizational  process  improvements  based  on  an 
understanding  of  the  current  strengths  and  weaknesses  of  the 
organization’s  processes  and  process  assets. 


10  Organizational  Process  Definition  (OPD)  has  one  goal  that  applies  only  when  using  CMMI  with  the  IPPD 
group  of  additions. 
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OPF  =  Organizational  Process  Focus 
OT  =  Organizational  Training 

OPD+IPPD  =  Organizational  Process  Definition  (with  the  IPPD  addition) 

Figure  4.1 :  Basic  Process  Management  Process  Areas 


Candidate  improvements  to  the  organization’s  processes  are  obtained 
through  various  means.  These  include  process  improvement  proposals, 
measurement  of  the  processes,  lessons  learned  in  implementing  the 
processes,  and  results  of  process  appraisal  and  product  evaluation 
activities. 

The  Organizational  Process  Definition  process  area  establishes  and 
maintains  the  organization’s  set  of  standard  processes,  work 
environment  standards,  and  other  assets  based  on  the  process  needs 
and  objectives  of  the  organization.  These  other  assets  include 
descriptions  of  lifecycle  models,  process  tailoring  guidelines,  and 
process-related  documentation  and  data.  Projects  tailor  the 
organization’s  set  of  standard  processes  to  create  their  defined 
processes.  The  other  assets  support  tailoring  as  well  as  implementation 
of  the  defined  processes.  Experiences  and  work  products  from 
performing  these  defined  processes,  including  measurement  data, 
process  descriptions,  process  artifacts,  and  lessons  learned,  are 
incorporated  as  appropriate  into  the  organization’s  set  of  standard 
processes  and  other  assets.  With  the  +IPPD  addition,  Organizational 
Process  Definition  +IPPD  provides  IPPD  rules  and  guidelines  to  the 
projects. 

The  Organizational  Training  process  area  identifies  the  strategic 
training  needs  of  the  organization  as  well  as  the  tactical  training  needs 
that  are  common  across  projects  and  support  groups.  In  particular, 
training  is  developed  or  obtained  to  develop  the  skills  required  to 
perform  the  organization’s  set  of  standard  processes.  The  main 
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components  of  training  include  a  managed  training  development 
program,  documented  plans,  personnel  with  appropriate  knowledge, 
and  mechanisms  for  measuring  the  effectiveness  of  the  training 
program. 

Advanced  Process  Management  Process  Areas 


The  Advanced  Process  Management  process  areas  provide  the 
organization  with  an  improved  capability  to  achieve  its  quantitative 
objectives  for  quality  and  process  performance. 

Figure  4.2  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Advanced  Process  Management  process  areas  and  with  other  process 
area  categories.  Each  of  the  Advanced  Process  Management  process 
areas  depends  on  the  ability  to  develop  and  deploy  processes  and 
supporting  assets.  The  Basic  Process  Management  process  areas 
provide  this  ability. 


OID  =  Organizational  Innovation  and  Deployment 
OPP  =  Organizational  Process  Performance 

Figure  4.2:  Advanced  Process  Management  Process  Areas 


As  illustrated  in  Figure  4.2,  the  Organizational  Process  Performance 
process  area  derives  quantitative  objectives  for  quality  and  process 
performance  from  the  organization’s  business  objectives.  The 
organization  provides  projects  and  support  groups  with  common 
measures,  process-performance  baselines,  and  process-performance 
models.  These  additional  organizational  assets  support  quantitative 
project  management  and  statistical  management  of  critical 
subprocesses  for  both  projects  and  support  groups.  The  organization 
analyzes  the  process-performance  data  collected  from  these  defined 
processes  to  develop  a  quantitative  understanding  of  product  quality, 
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service  quality,  and  process  performance  of  the  organization’s  set  of 
standard  processes. 

The  Organizational  Innovation  and  Deployment  process  area  selects 
and  deploys  proposed  incremental  and  innovative  improvements  that 
improve  the  organization’s  ability  to  meet  its  quality  and  process- 
performance  objectives.  The  identification  of  promising  incremental  and 
innovative  improvements  should  involve  the  participation  of  an 
empowered  workforce  aligned  with  the  business  values  and  objectives 
of  the  organization.  The  selection  of  improvements  to  deploy  is  based 
on  a  quantitative  understanding  of  the  likely  benefits  and  predictable 
costs  of  deploying  candidate  improvements,  and  the  funding  available 
for  such  deployment. 


Project  Management 


Project  Management  process  areas  cover  the  project  management 
activities  related  to  planning,  monitoring,  and  controlling  the  project. 

The  Project  Management  process  areas  of  CMMI  are  as  follows: 

•  Project  Planning 

•  Project  Monitoring  and  Control 

•  Supplier  Agreement  Management 

•  Integrated  Project  Management  +IPPD11 

•  Risk  Management 

•  Quantitative  Project  Management 

Basic  Project  Management  Process  Areas 


The  Basic  Project  Management  process  areas  address  the  activities 
related  to  establishing  and  maintaining  the  project  plan,  establishing 
and  maintaining  commitments,  monitoring  progress  against  the  plan, 
taking  corrective  action,  and  managing  supplier  agreements. 

Figure  4.3  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Basic  Project  Management  process  areas  and  with  other  process  area 
categories.  As  illustrated  in  Figure  4.3,  the  Project  Planning  process 
area  includes  developing  the  project  plan,  involving  stakeholders 
appropriately,  obtaining  commitment  to  the  plan,  and  maintaining  the 
plan.  When  using  IPPD,  stakeholders  represent  not  just  the  technical 
expertise  for  product  and  process  development,  but  also  the  business 
implications  of  product  and  process  development. 


11  Integrated  Project  Management  (IPM)  has  one  goal  that  applies  only  when  using  CMMI  with  the  IPPD  group 
of  additions. 
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PMC  =  Project  Monitoring  and  Control 

PP  =  Project  Planning 

SAM  =  Supplier  Agreement  Management 

Figure  4.3:  Basic  Project  Management  Process  Areas 


Planning  begins  with  requirements  that  define  the  product  and  project 
(“What  to  Build”  in  Figure  4.3).  The  project  plan  covers  the  various 
project  management  and  development  activities  performed  by  the 
project.  The  project  reviews  other  plans  that  affect  the  project  from 
various  relevant  stakeholders  and  establish  commitments  with  those 
stakeholders  for  their  contributions  to  the  project.  For  example,  these 
plans  cover  configuration  management,  verification,  and  measurement 
and  analysis. 

The  Project  Monitoring  and  Control  process  area  includes  monitoring 
activities  and  taking  corrective  action.  The  project  plan  specifies  the 
appropriate  level  of  project  monitoring,  the  frequency  of  progress 
reviews,  and  the  measures  used  to  monitor  progress.  Progress  is 
determined  primarily  by  comparing  project  status  to  the  plan.  When  the 
actual  status  deviates  significantly  from  the  expected  values,  corrective 
actions  are  taken  as  appropriate.  These  actions  may  include 
replanning. 

The  Supplier  Agreement  Management  process  area  addresses  the 
need  of  the  project  to  acquire  those  portions  of  work  that  are  produced 
by  suppliers.  Sources  of  products  that  may  be  used  to  satisfy  project 
requirements  are  proactively  identified.  The  supplier  is  selected,  and  a 
supplier  agreement  is  established  to  manage  the  supplier.  The 
supplier’s  progress  and  performance  are  tracked  by  monitoring  selected 
work  products  and  processes,  and  the  supplier  agreement  is  revised  as 
appropriate.  Acceptance  reviews  and  tests  are  conducted  on  the 
supplier-produced  product  component. 
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Advanced  Project  Management  Process  Areas 


The  Advanced  Project  Management  process  areas  address  activities 
such  as  establishing  a  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes,  establishing  the  project  work 
environment  from  the  organization’s  work  environment  standards, 
coordinating  and  collaborating  with  relevant  stakeholders,  managing 
risk,  forming  and  sustaining  integrated  teams  for  the  conduct  of 
projects,  and  quantitatively  managing  the  project’s  defined  process. 

Figure  4.4  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Advanced  Project  Management  process  areas  and  with  other  process 
area  categories.  Each  Advanced  Project  Management  process  area 
depends  on  the  ability  to  plan,  monitor,  and  control  the  project.  The 
Basic  Project  Management  process  areas  provide  this  ability. 


IPM+IPPD  =  Integrated  Project  Management  (with  the  IPPD  addition) 

QPM  =  Quantitative  Project  Management 
RSKM  =  Risk  Management 

Figure  4.4:  Advanced  Project  Management  Process  Areas 

The  Integrated  Project  Management  process  area  establishes  and 
maintains  the  project’s  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes.  The  project  is  managed  using 
the  project’s  defined  process.  The  project  uses  and  contributes  to  the 
organization’s  process  assets.  The  project’s  work  environment  is 
established  and  maintained  from  the  organization’s  work  environment 
standards. 

The  management  of  the  project  ensures  that  the  relevant  stakeholders 
associated  with  the  project  coordinate  their  efforts  in  a  timely  manner.  It 
does  this  by  providing  for  the  management  of  stakeholder  involvement; 
the  identification,  negotiation,  and  tracking  of  critical  dependencies;  and 
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the  resolution  of  coordination  issues  within  the  project  and  with  relevant 
stakeholders. 

With  the  +IPPD  addition,  Integrated  Project  Management  +IPPD 
establishes  and  maintains  the  shared  vision  of  the  project  and  an 
integrated  team  structure  for  the  project  and  then  establishes  integrated 
teams  to  perform  the  work  of  the  project,  ensuring  the  appropriate 
collaboration  across  teams. 

Although  risk  identification  and  monitoring  are  covered  in  the  Project 
Planning  and  Project  Monitoring  and  Control  process  areas,  the  Risk 
Management  process  area  takes  a  continuing,  forward-looking 
approach  to  managing  risks  with  activities  that  include  identification  of 
risk  parameters,  risk  assessments,  and  risk  mitigation. 

The  Quantitative  Project  Management  process  area  applies  quantitative 
and  statistical  techniques  to  manage  process  performance  and  product 
quality.  Quality  and  process-performance  objectives  for  the  project  are 
based  on  the  objectives  established  by  the  organization.  The  project’s 
defined  process  comprises,  in  part,  process  elements  and 
subprocesses  whose  process  performance  can  be  predicted.  At  a 
minimum,  the  process  variation  experienced  by  subprocesses  critical  to 
achieving  the  project’s  quality  and  process-performance  objectives  is 
understood.  Corrective  action  is  taken  when  special  causes  of  process 
variation  are  identified.  (See  the  definition  of  “special  cause  of  process 
variation”  in  the  glossary.) 


Engineering 


Engineering  process  areas  cover  the  development  and  maintenance 
activities  that  are  shared  across  engineering  disciplines.  The 
Engineering  process  areas  were  written  using  general  engineering 
terminology  so  that  any  technical  discipline  involved  in  the  product 
development  process  (e.g.,  software  engineering  or  mechanical 
engineering)  can  use  them  for  process  improvement. 

The  Engineering  process  areas  also  integrate  the  processes  associated 
with  different  engineering  disciplines  into  a  single  product  development 
process,  supporting  a  product-oriented  process  improvement  strategy. 
Such  a  strategy  targets  essential  business  objectives  rather  than 
specific  technical  disciplines.  This  approach  to  processes  effectively 
avoids  the  tendency  toward  an  organizational  “stovepipe”  mentality. 

The  Engineering  process  areas  apply  to  the  development  of  any 
product  or  service  in  the  development  domain  (e.g.,  software  products, 
hardware  products,  services,  or  processes). 


58 


Relationships  Among  Process  Areas 


CMMI  for  Development 
Version  1.2 


The  technical  foundation  for  IPPD  is  grounded  in  a  robust  systems 
engineering  approach  that  encompasses  development  in  the  context  of 
the  phases  of  the  product’s  life.  The  Engineering  process  areas  provide 
this  technical  foundation.  The  implementation  of  IPPD  is  further 
addressed  through  amplifications  to  specific  practices  in  the 
Engineering  process  areas  that  emphasize  concurrent  development 
and  focus  on  all  phases  of  the  product’s  life. 

The  Engineering  process  areas  of  CMMI  are  as  follows: 

•  Requirements  Development 

•  Requirements  Management 

•  Technical  Solution 

•  Product  Integration 

•  Verification 

•  Validation 

Figure  4.5  provides  a  bird’s-eye  view  of  the  interactions  among  the  six 
Engineering  process  areas. 


Customer  needs 


Figure  4.5:  Engineering  Process  Areas 


The  Requirements  Development  process  area  identifies  customer 
needs  and  translates  these  needs  into  product  requirements.  The  set  of 
product  requirements  is  analyzed  to  produce  a  high-level  conceptual 
solution.  This  set  of  requirements  is  then  allocated  to  establish  an  initial 
set  of  product  component  requirements.  Other  requirements  that  help 
define  the  product  are  derived  and  allocated  to  product  components. 
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This  set  of  product  and  product  component  requirements  clearly 
describes  the  product’s  performance,  design  features,  verification 
requirements,  and  so  forth,  in  terms  the  developer  understands  and 
uses. 

The  Requirements  Development  process  area  supplies  requirements  to 
the  Technical  Solution  process  area,  where  the  requirements  are 
converted  into  the  product  architecture,  the  product  component  design, 
and  the  product  component  itself  (e.g.,  coding  and  fabrication). 
Requirements  are  also  supplied  to  the  Product  Integration  process 
area,  where  product  components  are  combined  and  interfaces  are 
verified  to  ensure  that  they  meet  the  interface  requirements  supplied  by 
Requirements  Development. 

The  Requirements  Management  process  area  maintains  the 
requirements.  It  describes  activities  for  obtaining  and  controlling 
requirement  changes  and  ensuring  that  other  relevant  plans  and  data 
are  kept  current.  It  provides  traceability  of  requirements  from  customer 
to  product  to  product  component. 

Requirements  Management  ensures  that  changes  to  requirements  are 
reflected  in  project  plans,  activities,  and  work  products.  This  cycle  of 
changes  may  affect  all  the  other  Engineering  process  areas;  thus, 
requirements  management  is  a  dynamic  and  often  recursive  sequence 
of  events.  The  Requirements  Management  process  area  is  fundamental 
to  a  controlled  and  disciplined  engineering  design  process. 

The  Technical  Solution  process  area  develops  technical  data  packages 
for  product  components  that  will  be  used  by  the  Product  Integration  or 
Supplier  Agreement  Management  process  area.  Alternative  solutions 
are  examined  with  the  intent  of  selecting  the  optimum  design  based  on 
established  criteria.  These  criteria  may  be  significantly  different  across 
products,  depending  on  product  type,  operational  environment, 
performance  requirements,  support  requirements,  and  cost  or  delivery 
schedules.  The  task  of  selecting  the  final  solution  makes  use  of  the 
specific  practices  in  the  Decision  Analysis  and  Resolution  process  area. 

The  Technical  Solution  process  area  relies  on  the  specific  practices  in 
the  Verification  process  area  to  perform  design  verification  and  peer 
reviews  during  design  and  prior  to  final  build. 

The  Verification  process  area  ensures  that  selected  work  products  meet 
the  specified  requirements.  The  Verification  process  area  selects  work 
products  and  verification  methods  that  will  be  used  to  verify  work 
products  against  specified  requirements.  Verification  is  generally  an 
incremental  process,  starting  with  product  component  verification  and 
usually  concluding  with  verification  of  fully  assembled  products. 

Verification  also  addresses  peer  reviews.  Peer  reviews  are  a  proven 
method  for  removing  defects  early  and  provide  valuable  insight  into  the 
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work  products  and  product  components  being  developed  and 
maintained. 

The  Validation  process  area  incrementally  validates  products  against 
the  customer’s  needs.  Validation  may  be  performed  in  the  operational 
environment  or  in  a  simulated  operational  environment.  Coordination 
with  the  customer  on  the  validation  requirements  is  an  important 
element  of  this  process  area. 

The  scope  of  the  Validation  process  area  includes  validation  of 
products,  product  components,  selected  intermediate  work  products, 
and  processes.  These  validated  elements  may  often  require 
reverification  and  revalidation.  Issues  discovered  during  validation  are 
usually  resolved  in  the  Requirements  Development  or  Technical 
Solution  process  area. 

The  Product  Integration  process  area  contains  the  specific  practices 
associated  with  generating  the  best  possible  integration  sequence, 
integrating  product  components,  and  delivering  the  product  to  the 
customer. 

Product  Integration  uses  the  specific  practices  of  both  Verification  and 
Validation  in  implementing  the  product  integration  process.  Verification 
practices  verify  the  interfaces  and  interface  requirements  of  product 
components  prior  to  product  integration.  This  is  an  essential  event  in 
the  integration  process.  During  product  integration  in  the  operational 
environment,  the  specific  practices  of  the  Validation  process  area  are 
used. 

Recursion  and  Iteration  of  Engineering  Processes 


Most  process  standards  agree  that  there  are  two  ways  that  processes 
can  be  applied.  These  two  ways  are  called  recursion  and  iteration. 

Recursion  occurs  when  a  process  is  applied  to  successive  levels  of 
system  elements  within  a  system  structure.  The  outcomes  of  one 
application  are  used  as  inputs  to  the  next  level  in  the  system  structure. 
For  example,  the  verification  process  is  designed  to  apply  to  the  entire 
assembled  product,  the  major  product  components,  and  even 
components  of  components.  How  far  into  the  product  you  apply  the 
verification  process  depends  entirely  on  the  size  and  complexity  of  the 
end  product. 

Iteration  occurs  when  processes  are  repeated  at  the  same  system  level. 
New  information  is  created  by  the  implementation  of  one  process  that 
feeds  back  into  a  related  process.  This  new  information  typically  raises 
questions  that  must  be  resolved  before  completing  the  processes.  For 
example,  iteration  will  most  likely  occur  between  requirements 
development  and  technical  solution.  Reapplication  of  the  processes  can 
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resolve  the  questions  that  are  raised.  Iteration  can  ensure  quality  prior 
to  applying  the  next  process. 

Engineering  processes  (e.g.,  requirements  development  or  verification) 
are  implemented  repeatedly  on  a  product  to  ensure  that  these 
engineering  processes  have  been  adequately  addressed  before 
delivery  to  the  customer.  Further,  engineering  processes  are  applied  to 
components  of  the  product.  For  example,  some  questions  that  are 
raised  by  processes  associated  with  the  Verification  and  Validation 
process  areas  may  be  resolved  by  processes  associated  with  the 
Requirements  Development  or  Product  Integration  process  area. 
Recursion  and  iteration  of  these  processes  enable  the  project  to  ensure 
quality  in  all  components  of  the  product  before  it  is  delivered  to  the 
customer. 


Support 


Support  process  areas  cover  the  activities  that  support  product 
development  and  maintenance.  The  Support  process  areas  address 
processes  that  are  used  in  the  context  of  performing  other  processes.  In 
general,  the  Support  process  areas  address  processes  that  are 
targeted  toward  the  project  and  may  address  processes  that  apply  more 
generally  to  the  organization.  For  example,  Process  and  Product 
Quality  Assurance  can  be  used  with  all  the  process  areas  to  provide  an 
objective  evaluation  of  the  processes  and  work  products  described  in  all 
the  process  areas. 

The  Support  process  areas  of  CMMI  are  as  follows: 

•  Configuration  Management 

•  Process  and  Product  Quality  Assurance 

•  Measurement  and  Analysis 

•  Decision  Analysis  and  Resolution 

•  Causal  Analysis  and  Resolution 

Basic  Support  Process  Areas 


The  Basic  Support  process  areas  address  fundamental  support 
functions  that  are  used  by  all  process  areas.  Although  all  Support 
process  areas  rely  on  the  other  process  areas  for  input,  the  Basic 
Support  process  areas  provide  support  functions  that  also  help 
implement  several  generic  practices. 

Figure  4.6  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Basic  Support  process  areas  and  with  all  other  process  areas. 
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MA  =  Measurement  and  Analysis 
CM  =  Configuration  Management 
PPQA  =  Process  and  Product  Quality  Assurance 

Figure  4.6:  Basic  Support  Process  Areas 


The  Measurement  and  Analysis  process  area  supports  all  process 
areas  by  providing  specific  practices  that  guide  projects  and 
organizations  in  aligning  measurement  needs  and  objectives  with  a 
measurement  approach  that  will  provide  objective  results.  These  results 
can  be  used  in  making  informed  decisions  and  taking  appropriate 
corrective  actions. 

The  Process  and  Product  Quality  Assurance  process  area  supports  all 
process  areas  by  providing  specific  practices  for  objectively  evaluating 
performed  processes,  work  products,  and  services  against  the 
applicable  process  descriptions,  standards,  and  procedures,  and 
ensuring  that  any  issues  arising  from  these  reviews  are  addressed. 
Process  and  Product  Quality  Assurance  supports  the  delivery  of  high- 
quality  products  and  services  by  providing  the  project  staff  and  all  levels 
of  managers  with  appropriate  visibility  into,  and  feedback  on,  the 
processes  and  associated  work  products  throughout  the  life  of  the 
project. 

The  Configuration  Management  process  area  supports  all  process 
areas  by  establishing  and  maintaining  the  integrity  of  work  products 
using  configuration  identification,  configuration  control,  configuration 
status  accounting,  and  configuration  audits.  The  work  products  placed 
under  configuration  management  include  the  products  that  are 
delivered  to  the  customer,  designated  internal  work  products,  acquired 
products,  tools,  and  other  items  that  are  used  in  creating  and  describing 
these  work  products.  Examples  of  work  products  that  may  be  placed 
under  configuration  management  include  plans,  process  descriptions, 
requirements,  design  data,  drawings,  product  specifications,  code, 
compilers,  product  data  files,  and  product  technical  publications. 
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The  Advanced  Support  process  areas  provide  the  projects  and 
organization  with  an  improved  support  capability.  Each  of  these  process 
areas  relies  on  specific  inputs  or  practices  from  other  process  areas. 


Figure  4.7  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Advanced  Support  process  areas  and  with  all  other  process  areas. 


Figure  4.7:  Advanced  Support  Process  Areas 

Using  the  Causal  Analysis  and  Resolution  process  area,  project 
members  identify  causes  of  selected  defects  and  other  problems  and 
take  action  to  prevent  them  from  occurring  in  the  future.  While  the 
project’s  defined  processes  are  the  principal  targets  for  identifying  the 
cause  of  the  defect,  the  process  improvement  proposals  they  create 
target  the  organization’s  set  of  standard  processes,  which  will  prevent 
recurrence  of  the  defect  across  the  organization. 

The  Decision  Analysis  and  Resolution  process  area  supports  all  the 
process  areas  by  determining  which  issues  should  be  subjected  to  a 
formal  evaluation  process  and  then  applying  a  formal  evaluation 
process  to  them. 
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5  Using  CMMI  Models 


The  complexity  of  today’s  products  demands  an  integrated  view  of  how 
organizations  do  business.  CMMI  can  reduce  the  cost  of  process 
improvement  across  enterprises  that  depend  on  multiple  functions  or 
groups  to  produce  products  and  services. 

To  achieve  this  integrated  view,  the  CMMI  Framework  includes 
common  terminology,  common  model  components,  common  appraisal 
methods,  and  common  training  materials.  This  chapter  describes  how 
organizations  can  use  the  CMMI  Product  Suite  not  only  to  improve  their 
quality,  reduce  their  costs,  and  optimize  their  schedules,  but  also  to 
gauge  how  well  their  process  improvement  program  is  working. 


Adopting  CMMI 


Research  has  shown  that  the  most  powerful  initial  step  to  process 
improvement  is  to  build  strong  organizational  support  through  strong 
senior  management  sponsorship.  To  gain  senior  management 
sponsorship,  it  is  often  beneficial  to  expose  senior  management  to  the 
performance  results  experienced  by  others  who  have  used  CMMI  to 
improve  their  processes. 

For  more  information  about  CMMI  performance  results,  see  the  SEI 
Web  site  at  www.sei.cmu.edu/cmmi/results.html  [SEI  3], 

The  senior  manager,  once  committed  as  the  process  improvement 
sponsor,  must  be  actively  involved  in  the  CMMI-based  process 
improvement  effort.  Activities  performed  by  the  senior  management 
sponsor  include  (but  are  not  limited  to)  the  following: 

•  Influence  the  organization  to  adopt  CMMI. 

•  Choose  the  best  people  to  manage  the  process  improvement  effort. 

•  Monitor  the  process  improvement  effort  personally. 

•  Be  a  visible  advocate  and  spokesperson  for  the  process 
improvement  effort. 

•  Ensure  that  adequate  resources  are  available  to  enable  the  process 
improvement  effort  to  be  successful. 
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Given  sufficient  senior  management  sponsorship,  the  next  step  is 
establishing  a  strong,  technically  competent  process  group  that 
represents  relevant  stakeholders  to  guide  process  improvement  efforts. 

For  an  organization  with  a  mission  to  develop  software-intensive 
systems,  the  process  group  might  include  engineers  representing  the 
different  technical  disciplines  across  the  organization  and  other  selected 
members  based  on  the  business  needs  driving  improvement.  For 
example,  a  systems  administrator  may  focus  on  information-technology 
support,  whereas  a  marketing  representative  may  focus  on  integrating 
customers’  needs.  Both  members  could  make  powerful  contributions  to 
the  process  group. 

Once  your  organization  has  decided  to  adopt  CMMI,  planning  can  begin 
with  an  improvement  approach  such  as  the  IDEALSM  (Initiating, 
Diagnosing,  Establishing,  Acting,  &  Learning)  model.  For  more 
information  about  the  IDEAL  model,  see  the  SEI  Web  site  at 
www.sei.cmu.edu/ideal/ideal.html  [SEI  1], 


Your  Process  Improvement  Program 


Use  the  CMMI  Product  Suite  to  help  establish  your  organization’s 
process  improvement  program.  Using  the  product  suite  for  this  purpose 
can  be  a  relatively  informal  process  that  involves  understanding  and 
applying  CMMI  best  practices  to  your  organization.  Or,  it  can  be  a 
formal  process  that  involves  extensive  training,  creation  of  a  process 
improvement  infrastructure,  appraisals,  and  more. 


Selections  That  Influence  Your  Program 

You  must  make  three  selections  to  apply  CMMI  to  your  organization  for 
process  improvement: 

1 .  Select  a  part  of  the  organization. 

2.  Select  a  model. 

3.  Select  a  representation. 


Selecting  the  projects  to  be  involved  in  your  process  improvement 
program  is  critical.  If  you  select  a  group  that  is  too  large,  it  may  be  too 
much  for  the  initial  improvement  effort.  The  selection  should  also 
consider  how  homogeneous  the  group  is  (i.e.,  whether  they  all  are 
software  engineers,  whether  they  all  work  on  the  same  product  or 
business  line,  and  so  on). 
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Selecting  the  model  to  be  used  depends  on  the  areas  your  organization 
is  interested  in  improving.  Not  only  must  you  select  a  constellation  (e.g., 
Development,  Acquisition,  or  Services),  but  you  must  also  decide 
whether  to  include  any  additions  (e.g.,  IPPD). 

The  process  of  selecting  the  representation  to  be  used  has  some 
guidelines  because  of  how  CMMI  models  are  built.  If  your  organization 
likes  the  idea  of  maturity  levels  and  the  staged  representation,  your 
improvement  roadmap  is  already  defined.  If  your  organization  likes  the 
continuous  representation,  you  can  select  nearly  any  process  area  or 
group  of  process  areas  to  guide  improvement,  although  dependencies 
among  process  areas  should  be  considered  when  making  such  a 
selection. 

As  the  process  improvement  plans  and  activities  progress,  other 
important  selections  must  be  made,  including  which  appraisal  method 
should  be  used,  which  projects  should  be  appraised,  how  training  for 
personnel  should  be  secured,  and  which  personnel  should  be  trained. 


CMMI  Models 


CMMI  models  describe  what  have  been  determined  to  be  best  practices 
that  organizations  have  found  to  be  productive  and  useful  to  achieving 
their  business  objectives. 

Regardless  of  your  type  of  organization,  to  apply  CMMI  best  practices, 
you  must  use  professional  judgment  when  interpreting  them  for  your 
situation,  needs,  and  business  objectives.  Although  process  areas 
depict  the  characteristics  of  an  organization  committed  to  process 
improvement,  you  must  interpret  the  process  areas  using  an  in-depth 
knowledge  of  CMMI,  your  organization,  the  business  environment,  and 
the  specific  circumstances  involved. 

As  you  begin  using  a  CMMI  model  to  improve  your  organization’s 
processes,  map  your  real-world  processes  to  CMMI  process  areas.  This 
mapping  enables  you  to  initially  judge  and  later  track  your 
organization’s  level  of  conformance  to  the  CMMI  model  you  are  using 
and  to  identify  opportunities  for  improvement. 

To  interpret  practices,  it  is  important  to  consider  the  overall  context  in 
which  these  practices  are  used  and  to  determine  how  well  the  practices 
satisfy  the  goals  of  a  process  area  in  that  context.  CMMI  models  do  not 
explicitly  prescribe  nor  imply  particular  processes  that  are  right  for  any 
organization  or  project.  Instead,  CMMI  describes  minimal  criteria 
necessary  to  plan  and  implement  processes  selected  by  the 
organization  for  improvement  based  on  business  objectives. 
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CMMI  practices  purposely  use  nonspecific  phrases  such  as  “relevant 
stakeholders,”  “as  appropriate,”  and  “as  necessary”  to  accommodate 
the  needs  of  different  organizations  and  projects.  The  specific  needs  of 
a  project  may  also  differ  at  various  points  during  its  life. 


Using  CMMI  Appraisals 


Many  organizations  find  value  in  measuring  their  progress  by 
conducting  an  appraisal  and  thus  earning  a  maturity  level  rating  or  a 
capability  level  achievement  profile.  These  appraisals  are  typically 
conducted  for  one  or  more  of  the  following  reasons: 

•  To  determine  how  well  the  organization’s  processes  compare  to 
CMMI  best  practices  and  identify  areas  where  improvement  can  be 
made 

•  To  inform  external  customers  and  suppliers  about  how  well  the 
organization’s  processes  compare  to  CMMI  best  practices 

•  To  meet  the  contract  requirements  of  one  or  more  customers 

Appraisals  of  organizations  using  a  CMMI  model  must  conform  to  the 
requirements  defined  in  the  Appraisal  Requirements  for  CMMI  (ARC) 
document.  These  appraisals  focus  on  identifying  improvement 
opportunities  and  comparing  the  organization’s  processes  to  CMMI  best 
practices.  Appraisal  teams  use  a  CMMI  model  and  ARC-conformant 
appraisal  method  to  guide  their  evaluation  of  the  organization  as  well  as 
how  they  report  their  conclusions.  The  appraisal  results  are  then  used 
(by  a  process  group,  for  example)  to  plan  improvements  for  the 
organization. 

Appraisal  Requirements  for  CMMI 


The  ARC  document  describes  the  requirements  for  several  types  of 
appraisals.  A  full  benchmarking  class  of  appraisal  is  defined  as  a  Class 
A  appraisal.  Less  formal  methods  are  defined  as  Class  B  or  Class  C 
methods.  The  ARC  document  was  designed  to  help  improve 
consistency  across  appraisal  methods,  and  to  help  appraisal  method 
developers,  sponsors,  and  users  understand  the  tradeoffs  associated 
with  various  methods  [SEI  2006a], 

Depending  on  the  purpose  of  the  appraisal  and  the  nature  of  the 
circumstances,  one  class  may  be  preferred  over  the  others.  Sometimes 
self-assessments,  initial  appraisals,  quick-look,  or  mini-appraisals, 
incremental  appraisals,  or  external  appraisals  are  appropriate,  and 
other  times  a  formal  benchmarking  appraisal  is  appropriate. 
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A  particular  appraisal  method  is  declared  an  ARC  Class  A,  B,  or  C 
appraisal  method  based  on  the  sets  of  ARC  requirements  that  the 
method  developer  addressed  when  designing  the  method. 

More  information  about  the  ARC  is  available  on  the  SEI  Web  site  at 
www.sei.cmu.edu/cmmi/appraisals/appraisals.html. 

SCAMPI  Appraisal  Methods 


The  SCAMPI  appraisal  methods  are  the  generally  accepted  methods 
used  for  conducting  appraisals  using  CMMI  models.  The  SCAMPI 
Method  Definition  Document  (MDD)  defines  rules  for  ensuring  the 
consistency  of  appraisal  ratings.  For  benchmarking  against  other 
organizations,  appraisals  must  ensure  consistent  ratings.  The 
achievement  of  a  specific  maturity  level  or  the  satisfaction  of  a  process 
area  must  mean  the  same  thing  for  different  appraised  organizations. 

The  SCAMPI  family  of  appraisals  includes  Class  A,  B,  and  C  appraisal 
methods.  SCAMPI  A  is  the  most  rigorous  method  and  the  only  method 
that  can  result  in  a  rating.  SCAMPI  B  provides  options  in  model  scope, 
but  the  characterization  of  practices  is  fixed  to  one  scale  and  is 
performed  on  implemented  practices.  SCAMPI  C  provides  a  wide  range 
of  options,  including  characterization  of  planned  approaches  to  process 
implementation  according  to  a  scale  defined  by  the  user. 

More  information  about  SCAMPI  methods  is  available  on  the  SEI  Web 
site  atwww.sei.cmu.edu/cmmi/appraisals/appraisals.html  [SEI  2006b], 


Appraisal  Considerations 


Choices  that  affect  a  CMMI-based  appraisal  include  the  following: 

•  Which  CMMI  model  to  use  for  the  appraisal  (for  this  constellation, 
the  choice  would  be  between  the  CMMI  for  Development  model  and 
the  CMMI  for  Development  +IPPD  model) 

•  Establishing  the  appraisal  scope,  including  the  organizational  unit  to 
be  appraised,  the  CMMI  process  areas  to  be  investigated,  and  the 
maturity  level  or  capability  level(s)  to  be  appraised 

•  Selecting  the  appraisal  method 

•  Selecting  the  appraisal  team  members 

•  Selecting  appraisal  participants  from  the  appraisal  entities  to  be 
interviewed 

•  Establishing  appraisal  outputs  (e.g.,  ratings  or  instantiation-specific 
findings) 

•  Establishing  appraisal  constraints  (e.g.,  time  spent  on  site) 
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The  SCAMPI  MDD  allows  the  selection  of  predefined  options  for  use  in 
an  appraisal.  These  appraisal  options  are  designed  to  help 
organizations  align  CMMI  with  their  business  needs  and  objectives. 

Documentation  of  CMMI  appraisal  plans  and  results  must  always 
include  a  description  of  the  appraisal  options,  model  scope,  and 
organizational  scope  selected.  This  documentation  confirms  whether  an 
appraisal  meets  the  requirements  for  benchmarking. 

For  organizations  that  wish  to  appraise  multiple  functions  or  groups, 
CMMI’s  integrated  approach  enables  some  economy  of  scale  in  model 
and  appraisal  training.  One  appraisal  method  can  provide  separate  or 
combined  results  for  multiple  functions. 

The  appraisal  principles  for  the  CMMI  Product  Suite12  remain  the  same 
as  those  used  in  appraisals  for  other  process  improvement  models. 
Those  principles  are  as  follows: 

•  Senior  management  sponsorship13 

•  A  focus  on  the  organization’s  business  objectives 

•  Confidentiality  for  interviewees 

•  Use  of  a  documented  appraisal  method 

•  Use  of  a  process  reference  model  (e.g.,  a  CMMI  model)  as  a  base 

•  A  collaborative  team  approach 

•  A  focus  on  actions  for  process  improvement 


CMMI-Related  Training 


Whether  your  organization  is  new  to  process  improvement  or  is  already 
familiar  with  process  improvement  models,  training  is  a  key  element  in 
the  ability  of  organizations  to  adopt  CMMI.  An  initial  set  of  courses  is 
provided  by  the  SEI  and  its  Partners,  but  your  organization  may  wish  to 
supplement  these  courses  with  internal  instruction.  This  approach 
allows  your  organization  to  focus  on  the  areas  that  provide  the  greatest 
business  value. 

The  SEI  and  its  Partners  offer  the  Introduction  to  CMMI  course,  which 
provides  a  basic  overview  of  the  CMMI  models.  The  SEI  also  offers  the 
Intermediate  Concepts  of  CMMI  course  to  those  who  plan  to  become 
more  deeply  involved  in  CMMI  adoption  or  appraisal — for  example, 
those  who  will  guide  improvement  as  part  of  a  process  group,  those 
who  will  lead  SCAMPI  appraisals,  and  those  who  will  teach  the 


12  See  the  glossary  for  the  definition  of  CMMI  Product  Suite. 

13  Experience  has  shown  that  the  most  critical  factor  influencing  successful  process  improvement  and  appraisals 
is  senior  management  sponsorship. 
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Introduction  to  CMM  course.  Current  information  about  CMMI-related 
training  is  available  on  the  SEI  Web  site  at 
www.sei.cmu.edu/cmmi/traininq/traininq.html. 
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Part  Two 

Generic  Goals  and  Generic  Practices, 
and  the  Process  Areas 
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GENERIC  GOALS  AND  GENERIC  PRACTICES 


Overview 


This  section  describes,  in  detail,  all  the  generic  goals  and  generic 
practices  of  CMMI — model  components  that  directly  address  process 
institutionalization. 

In  the  process  areas,  generic  goals  and  generic  practices  appear  at  the 
end  of  each  process  area.  Generic  practice  elaborations  appear  after 
generic  practices  to  show  how  these  practices  should  uniquely  be 
applied  to  the  process  area. 

The  entire  text  of  the  generic  goals  and  generic  practices  is  not 
repeated  in  the  process  areas  (i.e.,  subpractices,  notes,  examples,  and 
references  are  omitted).  Instead,  only  the  generic  goal  and  generic 
practice  titles  and  statements  appear.  As  you  address  each  process 
area,  refer  to  this  section  for  the  details  of  all  generic  practices. 


Process  Institutionalization 


Institutionalization  is  an  important  concept  in  process  improvement. 
When  mentioned  in  the  generic  goal  and  generic  practice  descriptions, 
institutionalization  implies  that  the  process  is  ingrained  in  the  way  the 
work  is  performed  and  there  is  commitment  and  consistency  to 
performing  the  process. 

An  institutionalized  process  is  more  likely  to  be  retained  during  times  of 
stress.  When  the  requirements  and  objectives  for  the  process  change, 
however,  the  implementation  of  the  process  may  also  need  to  change 
to  ensure  that  it  remains  effective.  The  generic  practices  describe 
activities  that  address  these  aspects  of  institutionalization. 

The  degree  of  institutionalization  is  embodied  in  the  generic  goals  and 
expressed  in  the  names  of  the  processes  associated  with  each  goal  as 
indicated  in  Table  6.1 . 
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Table  6.1  Generic  Goals  and  Process  Names 


Generic  Goal 

Progression  of  Processes 

GG  1 

Performed  process 

GG  2 

Managed  process 

GG  3 

Defined  process 

GG  4 

Quantitatively  managed  process 

GG  5 

Optimizing  process 

The  progression  of  process  institutionalization  is  characterized  in  the 
following  descriptions  of  each  process. 

Performed  Process 


A  performed  process  is  a  process  that  accomplishes  the  work 
necessary  to  produce  work  products.  The  specific  goals  of  the  process 
area  are  satisfied. 

Managed  Process 


A  managed  process  is  a  performed  process  that  is  planned  and 
executed  in  accordance  with  policy;  employs  skilled  people  who  have 
adequate  resources  to  produce  controlled  outputs;  involves  relevant 
stakeholders;  is  monitored,  controlled,  and  reviewed;  and  is  evaluated 
for  adherence  to  its  process  description.  The  process  may  be 
instantiated  by  a  project,  group,  or  organizational  function.  Management 
of  the  process  is  concerned  with  institutionalization  and  the 
achievement  of  other  specific  objectives  established  for  the  process, 
such  as  cost,  schedule,  and  quality  objectives.  The  control  provided  by 
a  managed  process  helps  to  ensure  that  the  established  process  is 
retained  during  times  of  stress. 

The  requirements  and  objectives  for  the  process  are  established  by  the 
organization.  The  status  of  the  work  products  and  delivery  of  the 
services  are  visible  to  management  at  defined  points  (e.g.,  at  major 
milestones  and  completion  of  major  tasks).  Commitments  are 
established  among  those  performing  the  work  and  the  relevant 
stakeholders  and  are  revised  as  necessary.  Work  products  are 
reviewed  with  relevant  stakeholders  and  are  controlled.  The  work 
products  and  services  satisfy  their  specified  requirements. 

A  critical  distinction  between  a  performed  process  and  a  managed 
process  is  the  extent  to  which  the  process  is  managed.  A  managed 
process  is  planned  (the  plan  may  be  part  of  a  more  encompassing  plan) 
and  the  performance  of  the  process  is  managed  against  the  plan. 
Corrective  actions  are  taken  when  the  actual  results  and  performance 
deviate  significantly  from  the  plan.  A  managed  process  achieves  the 
objectives  of  the  plan  and  is  institutionalized  for  consistent  performance. 
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Defined  Process 


A  defined  process  is  a  managed  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description;  and 
contributes  work  products,  measures,  and  other  process  improvement 
information  to  the  organizational  process  assets. 

The  organizational  process  assets  are  artifacts  that  relate  to  describing, 
implementing,  and  improving  processes.  These  artifacts  are  assets 
because  they  are  developed  or  acquired  to  meet  the  business 
objectives  of  the  organization,  and  they  represent  investments  by  the 
organization  that  are  expected  to  provide  current  and  future  business 
value. 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the 
defined  process,  are  established  and  improved  overtime.  Standard 
processes  describe  the  fundamental  process  elements  that  are 
expected  in  the  defined  processes.  Standard  processes  also  describe 
the  relationships  (e.g.,  the  ordering  and  the  interfaces)  among  these 
process  elements.  The  organization-level  infrastructure  to  support 
current  and  future  use  of  the  organization’s  set  of  standard  processes  is 
established  and  improved  overtime.  (See  the  definition  of  “standard 
process”  in  the  glossary.) 

A  project’s  defined  process  provides  a  basis  for  planning,  performing, 
and  improving  the  project’s  tasks  and  activities.  A  project  may  have 
more  than  one  defined  process  (e.g.,  one  for  developing  the  product 
and  another  for  testing  the  product). 

A  defined  process  clearly  states  the  following: 

•  Purpose 

•  Inputs 

•  Entry  criteria 

•  Activities 

•  Roles 

•  Measures 

•  Verification  steps 

•  Outputs 

•  Exit  criteria 

A  critical  distinction  between  a  managed  process  and  a  defined  process 
is  the  scope  of  application  of  the  process  descriptions,  standards,  and 
procedures.  Fora  managed  process,  the  process  descriptions, 
standards,  and  procedures  are  applicable  to  a  particular  project,  group, 
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or  organizational  function.  As  a  result,  the  managed  processes  of  two 
projects  in  one  organization  may  be  different. 

Another  critical  distinction  is  that  a  defined  process  is  described  in  more 
detail  and  is  performed  more  rigorously  than  a  managed  process.  This 
means  that  improvement  information  is  easier  to  understand,  analyze, 
and  use.  Finally,  management  of  the  defined  process  is  based  on  the 
additional  insight  provided  by  an  understanding  of  the  interrelationships 
of  the  process  activities  and  detailed  measures  of  the  process,  its  work 
products,  and  its  services. 

Quantitatively  Managed  Process 


A  quantitatively  managed  process  is  a  defined  process  that  is  controlled 
using  statistical  and  other  quantitative  techniques.  The  product  quality, 
service  quality,  and  process-performance  attributes  are  measurable  and 
controlled  throughout  the  project. 

Quantitative  objectives  are  established  based  on  the  capability  of  the 
organization’s  set  of  standard  processes;  the  organization’s  business 
objectives;  and  the  needs  of  the  customer,  end  users,  organization,  and 
process  implementers,  subject  to  the  availability  of  resources.  The 
people  performing  the  process  are  directly  involved  in  quantitatively 
managing  the  process. 

Quantitative  management  is  performed  on  the  overall  set  of  processes 
that  produces  a  product.  The  subprocesses  that  are  significant 
contributors  to  overall  process  performance  are  statistically  managed. 
For  these  selected  subprocesses,  detailed  measures  of  process 
performance  are  collected  and  statistically  analyzed.  Special  causes  of 
process  variation  are  identified  and,  where  appropriate,  the  source  of 
the  special  cause  is  addressed  to  prevent  its  recurrence. 

The  quality  and  process-performance  measures  are  incorporated  into 
the  organization’s  measurement  repository  to  support  future  fact-based 
decision  making. 

Activities  for  quantitatively  managing  the  performance  of  a  process 
include  the  following: 

•  Identifying  the  subprocesses  that  are  to  be  brought  under  statistical 
management 

•  Identifying  and  measuring  product  and  process  attributes  that  are 
important  contributors  to  quality  and  process  performance 

•  Identifying  and  addressing  special  causes  of  subprocess  variations 
(based  on  the  selected  product  and  process  attributes  and 
subprocesses  selected  for  statistical  management) 
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•  Managing  each  of  the  selected  subprocesses,  with  the  objective  of 
bringing  their  performance  within  natural  bounds  (i.e.,  making  the 
subprocess  performance  statistically  stable  and  predictable  based 
on  the  selected  product  and  process  attributes) 

•  Predicting  the  ability  of  the  process  to  satisfy  established 
quantitative  quality  and  process-performance  objectives 

•  Taking  appropriate  corrective  actions  when  it  is  determined  that  the 
established  quantitative  quality  and  process-performance  objectives 
will  not  be  satisfied 

These  corrective  actions  include  changing  the  objectives  or  ensuring 
that  relevant  stakeholders  have  a  quantitative  understanding  of,  and 
have  agreed  to,  the  performance  shortfall. 

A  critical  distinction  between  a  defined  process  and  a  quantitatively 
managed  process  is  the  predictability  of  process  performance.  The  term 
quantitatively  managed  implies  using  appropriate  statistical  and  other 
quantitative  techniques  to  manage  the  performance  of  one  or  more 
critical  subprocesses  so  that  the  performance  of  the  process  can  be 
predicted.  A  defined  process  provides  only  qualitative  predictability. 

Optimizing  Process 


An  optimizing  process  is  a  quantitatively  managed  process  that  is 
changed  and  adapted  to  meet  relevant  current  and  projected  business 
objectives.  An  optimizing  process  focuses  on  continually  improving 
process  performance  through  both  incremental  and  innovative 
technological  improvements.  Process  improvements  that  address 
common  causes  of  process  variation,  root  causes  of  defects,  and  other 
problems;  and  those  that  would  measurably  improve  the  organization’s 
processes  are  identified,  evaluated,  and  deployed  as  appropriate. 

These  improvements  are  selected  based  on  a  quantitative 
understanding  of  their  expected  contribution  to  achieving  the 
organization’s  process  improvement  objectives  versus  the  cost  and 
impact  to  the  organization. 

Selected  incremental  and  innovative  technological  process 
improvements  are  systematically  managed  and  deployed  into  the 
organization.  The  effects  of  the  deployed  process  improvements  are 
measured  and  evaluated  against  the  quantitative  process  improvement 
objectives. 

In  a  process  that  is  optimized,  common  causes  of  process  variation  are 
addressed  by  changing  the  process  in  a  way  that  will  shift  the  mean  or 
decrease  variation  when  the  process  is  restabilized.  These  changes  are 
intended  to  improve  process  performance  and  to  achieve  the 
organization’s  established  process  improvement  objectives. 
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A  critical  distinction  between  a  quantitatively  managed  process  and  an 
optimizing  process  is  that  the  optimizing  process  is  continuously 
improved  by  addressing  common  causes  of  process  variation.  A 
quantitatively  managed  process  is  concerned  with  addressing  special 
causes  of  process  variation  and  providing  statistical  predictability  of  the 
results.  Although  the  process  may  produce  predictable  results,  the 
results  may  be  insufficient  to  achieve  the  organization’s  process 
improvement  objectives. 

Relationships  among  Processes 


The  generic  goals  evolve  so  that  each  goal  provides  a  foundation  for 
the  next.  Therefore  the  following  conclusions  can  be  made: 

•  A  managed  process  is  a  performed  process. 

•  A  defined  process  is  a  managed  process. 

•  A  quantitatively  managed  process  is  a  defined  process. 

•  An  optimizing  process  is  a  quantitatively  managed  process. 

Thus,  applied  sequentially  and  in  order,  the  generic  goals  describe  a 
process  that  is  increasingly  institutionalized  from  a  performed  process 
to  an  optimizing  process. 

Achieving  GG  1  for  a  process  area  is  equivalent  to  saying  you  achieve 
the  specific  goals  of  the  process  area. 

Achieving  GG  2  for  a  process  area  is  equivalent  to  saying  you  manage 
the  performance  of  processes  associated  with  the  process  area.  There 
is  a  policy  that  indicates  you  will  perform  it.  There  is  a  plan  for 
performing  it.  There  are  resources  provided,  responsibilities  assigned, 
training  on  how  to  perform  it,  selected  work  products  from  performing 
the  process  are  controlled,  and  so  on.  In  other  words,  the  process  is 
planned  and  monitored  just  like  any  project  or  support  activity. 

Achieving  GG  3  for  a  process  area  assumes  that  an  organizational 
standard  process  exists  that  can  be  tailored  to  result  in  the  process  you 
will  use.  Tailoring  might  result  in  making  no  changes  to  the  standard 
process.  In  other  words,  the  process  used  and  the  standard  process 
may  be  identical.  Using  the  standard  process  “as  is”  is  tailoring  because 
the  choice  is  made  that  no  modification  is  required. 

Each  process  area  describes  multiple  activities,  some  of  which  are 
repeatedly  performed.  You  may  need  to  tailor  the  way  one  of  these 
activities  is  performed  to  account  for  new  capabilities  or  circumstances. 
For  example,  you  may  have  a  standard  for  developing  or  obtaining 
organizational  training  that  does  not  consider  Web-based  training. 

When  preparing  to  develop  or  obtain  a  Web-based  course,  you  may 
need  to  tailor  the  standard  process  to  account  for  the  particular 
challenges  and  benefits  of  Web-based  training. 
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Achieving  GG  4  or  GG  5  for  a  process  area  is  conceptually  feasible  but 
may  not  be  economical  except,  perhaps,  in  situations  where  the  product 
domain  has  become  stable  for  an  extended  period  or  in  situations  in 
which  the  process  area  or  domain  is  a  critical  business  driver. 


Generic  Goals  and  Generic  Practices 


This  section  describes  all  of  the  generic  goals  and  generic  practices,  as 
well  as  their  associated  subpractices,  notes,  examples,  and  references. 
The  generic  goals  are  organized  in  numerical  order,  GG  1  through  GG 
5.  The  generic  practices  are  also  organized  in  numerical  order  under 
the  generic  goal  they  support. 

As  mentioned  earlier,  the  subpractices,  notes,  examples,  and 
references  are  not  repeated  in  the  process  areas;  the  details  of  each 
generic  goal  and  generic  practice  are  found  only  here. 


GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 


GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  process  area  to  develop 
work  products  and  provide  services  to  achieve  the  specific 
goals  of  the  process  area. 


The  purpose  of  this  generic  practice  is  to  produce  the  work  products 
and  deliver  the  services  that  are  expected  by  performing  the  process 
These  practices  may  be  done  informally,  without  following  a 
documented  process  description  or  plan.  The  rigor  with  which  these 
practices  are  performed  depends  on  the  individuals  managing  and 
performing  the  work  and  may  vary  considerably. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  process. 


The  purpose  of  this  generic  practice  is  to  define  the  organizational 
expectations  for  the  process  and  make  these  expectations  visible  to 
those  in  the  organization  who  are  affected.  In  general,  senior 
management  is  responsible  for  establishing  and  communicating  guiding 
principles,  direction,  and  expectations  for  the  organization. 
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Not  all  direction  from  senior  management  will  bear  the  label  “policy.” 
The  existence  of  appropriate  organizational  direction  is  the  expectation 
of  this  generic  practice,  regardless  of  what  it  is  called  or  how  it  is 
imparted. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process. 


The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to 
perform  the  process  and  to  achieve  the  established  objectives,  to 
prepare  a  plan  for  performing  the  process,  to  prepare  a  process 
description,  and  to  get  agreement  on  the  plan  from  relevant 
stakeholders. 

The  practical  implications  of  applying  a  generic  practice  vary  for  each 
process  area.  For  example,  the  planning  described  by  this  generic 
practice  as  applied  to  the  Project  Monitoring  and  Control  process  area 
may  be  carried  out  in  full  by  the  processes  associated  with  the  Project 
Planning  process  area.  However,  this  generic  practice,  when  applied  to 
the  Project  Planning  process  area,  sets  an  expectation  that  the  project 
planning  process  itself  be  planned.  Therefore,  this  generic  practice  may 
either  reinforce  expectations  set  elsewhere  in  CMMI  or  set  new 
expectations  that  should  be  addressed. 

Refer  to  the  Project  Planning  process  area  for  more  information  on 
establishing  and  maintaining  a  project  plan. 

Establishing  a  plan  includes  documenting  the  plan  and  a  process 
description.  Maintaining  the  plan  includes  updating  it  to  reflect 
corrective  actions  or  changes  in  requirements  or  objectives. 

The  plan  for  performing  the  process  typically  includes  the  following: 

•  Process  description 

•  Standards  and  requirements  for  the  work  products  and  services  of 
the  process 

•  Specific  objectives  for  the  performance  of  the  process  (e.g.,  quality, 
time  scale,  cycle  time,  and  resource  usage) 

•  Dependencies  among  the  activities,  work  products,  and  services  of 
the  process 

•  Resources  (including  funding,  people,  and  tools)  needed  to  perform 
the  process 

•  Assignment  of  responsibility  and  authority 

•  Training  needed  for  performing  and  supporting  the  process 

•  Work  products  to  be  controlled  and  the  level  of  control  to  be  applied 
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•  Measurement  requirements  to  provide  insight  into  the  performance 
of  the  process,  its  work  products,  and  its  services 

•  Involvement  of  identified  stakeholders 

•  Activities  for  monitoring  and  controlling  the  process 

•  Objective  evaluation  activities  of  the  process 

•  Management  review  activities  for  the  process  and  the  work  products 

Subpractices 

1 .  Define  and  document  the  plan  for  performing  the  process. 

This  plan  may  be  a  stand-alone  document,  embedded  in  a  more  comprehensive 
document,  or  distributed  across  multiple  documents.  In  the  case  of  the  plan  being 
distributed  across  multiple  documents,  ensure  that  a  coherent  picture  of  who  does 
what  is  preserved.  Documents  may  be  hardcopy  or  softcopy. 

2.  Define  and  document  the  process  description. 

The  process  description,  which  includes  relevant  standards  and  procedures,  may 
be  included  as  part  of  the  plan  for  performing  the  process  or  may  be  included  in 
the  plan  by  reference. 

3.  Review  the  plan  with  relevant  stakeholders  and  get  their 
agreement. 

This  includes  reviewing  that  the  planned  process  satisfies  the  applicable  policies, 
plans,  requirements,  and  standards  to  provide  assurance  to  relevant 
stakeholders. 

4.  Revise  the  plan  as  necessary. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  process. 


The  purpose  of  this  generic  practice  is  to  ensure  that  the  resources 
necessary  to  perform  the  process  as  defined  by  the  plan  are  available 
when  they  are  needed.  Resources  include  adequate  funding, 
appropriate  physical  facilities,  skilled  people,  and  appropriate  tools. 

The  interpretation  of  the  term  “adequate”  depends  on  many  factors  and 
can  change  overtime.  Inadequate  resources  may  be  addressed  by 
increasing  resources  or  by  removing  requirements,  constraints,  and 
commitments. 
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GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  process. 


The  purpose  of  this  generic  practice  is  to  ensure  that  there  is 
accountability  for  performing  the  process  and  achieving  the  specified 
results  throughout  the  life  of  the  process.  The  people  assigned  must 
have  the  appropriate  authority  to  perform  the  assigned  responsibilities. 

Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in 
living  documents,  such  as  the  plan  for  performing  the  process.  Dynamic 
assignment  of  responsibility  is  another  legitimate  way  to  perform  this 
generic  practice,  as  long  as  the  assignment  and  acceptance  of 
responsibility  are  ensured  throughout  the  life  of  the  process. 

Subpractices 

1 .  Assign  overall  responsibility  and  authority  for  performing  the 
process. 

2.  Assign  responsibility  and  authority  for  performing  the  specific  tasks 
of  the  process. 

3.  Confirm  that  the  people  assigned  to  the  responsibilities  and 
authorities  understand  and  accept  them. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  as 
needed. 


The  purpose  of  this  generic  practice  is  to  ensure  that  the  people  have 
the  necessary  skills  and  expertise  to  perform  or  support  the  process. 

Appropriate  training  is  provided  to  the  people  who  will  be  performing  the 
work.  Overview  training  is  provided  to  orient  people  who  interact  with 
those  performing  the  work. 

Examples  of  methods  for  providing  training  include  self-study;  self- 
directed  training;  self-paced,  programmed  instruction;  formalized  on- 
the-job  training;  mentoring;  and  formal  and  classroom  training. 

Training  supports  the  successful  performance  of  the  process  by 
establishing  a  common  understanding  of  the  process  and  by  imparting 
the  skills  and  knowledge  needed  to  perform  the  process. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  training  the  people  performing  or  supporting  the  process. 
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GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  process  under 
appropriate  levels  of  control. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
integrity  of  the  designated  work  products  of  the  process  (or  their 
descriptions)  throughout  their  useful  life. 

The  designated  work  products  are  specifically  identified  in  the  plan  for 
performing  the  process,  along  with  a  specification  of  the  appropriate 
level  of  control. 

Different  levels  of  control  are  appropriate  for  different  work  products  and 
for  different  points  in  time.  For  some  work  products,  it  may  be  sufficient 
to  maintain  version  control  (i.e. ,  the  version  of  the  work  product  in  use 
at  a  given  time,  past  or  present,  is  known,  and  changes  are 
incorporated  in  a  controlled  manner).  Version  control  is  usually  under 
the  sole  control  of  the  work  product  owner  (which  may  be  an  individual, 
a  group,  or  a  team). 

Sometimes,  it  may  be  critical  that  work  products  be  placed  under  formal 
or  baseline  configuration  management.  This  type  of  control  includes 
defining  and  establishing  baselines  at  predetermined  points.  These 
baselines  are  formally  reviewed  and  agreed  on,  and  serve  as  the  basis 
for  further  development  of  the  designated  work  products. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  placing  work  products  under  configuration 
management. 

Additional  levels  of  control  between  version  control  and  formal 
configuration  management  are  possible.  An  identified  work  product  may 
be  under  various  levels  of  control  at  different  points  in  time. 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  process  as 
planned. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
expected  involvement  of  stakeholders  during  the  execution  of  the 
process. 

Involve  relevant  stakeholders  as  described  in  an  appropriate  plan  for 
stakeholder  involvement.  Involve  stakeholders  appropriately  in  activities 
such  as  the  following: 

•  Planning 

•  Decisions 

•  Commitments 
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•  Communications 

•  Coordination 

•  Reviews 

•  Appraisals 

•  Requirements  definitions 

•  Resolution  of  problems/issues 

Refer  to  the  Project  Planning  process  area  for  information  on  the  project 
planning  for  stakeholder  involvement. 

The  objective  of  planning  stakeholder  involvement  is  to  ensure  that 
interactions  necessary  to  the  process  are  accomplished,  while  not 
allowing  excessive  numbers  of  affected  groups  and  individuals  to 
impede  process  execution. 

Subpractices 

1 .  Identify  stakeholders  relevant  to  this  process  and  their  appropriate 
involvement. 

Relevant  stakeholders  are  identified  among  the  suppliers  of  inputs  to,  the  users  of 
outputs  from,  and  the  performers  of  the  activities  within  the  process.  Once  the 
relevant  stakeholders  are  identified,  the  appropriate  level  of  their  involvement  in 
process  activities  is  planned. 

2.  Share  these  identifications  with  project  planners  or  other  planners 
as  appropriate. 

3.  Involve  relevant  stakeholders  as  planned. 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  against  the  plan  for  performing 
the  process  and  take  appropriate  corrective  action. 


The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day 
monitoring  and  controlling  of  the  process.  Appropriate  visibility  into  the 
process  is  maintained  so  that  appropriate  corrective  action  can  be  taken 
when  necessary.  Monitoring  and  controlling  the  process  involves 
measuring  appropriate  attributes  of  the  process  or  work  products 
produced  by  the  process. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  and  taking 
corrective  action. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  measurement. 
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Subpractices 

1 .  Measure  actual  performance  against  the  plan  for  performing  the 
process. 

The  measures  are  of  the  process,  its  work  products,  and  its  services. 

2.  Review  accomplishments  and  results  of  the  process  against  the 
plan  for  performing  the  process. 

3.  Review  activities,  status,  and  results  of  the  process  with  the 
immediate  level  of  management  responsible  for  the  process  and 
identify  issues.  The  reviews  are  intended  to  provide  the  immediate 
level  of  management  with  appropriate  visibility  into  the  process. 

The  reviews  can  be  both  periodic  and  event  driven. 

4.  Identify  and  evaluate  the  effects  of  significant  deviations  from  the 
plan  for  performing  the  process. 

5.  Identify  problems  in  the  plan  for  performing  the  process  and  in  the 
execution  of  the  process. 

6.  Take  corrective  action  when  requirements  and  objectives  are  not 
being  satisfied,  when  issues  are  identified,  or  when  progress  differs 
significantly  from  the  plan  for  performing  the  process. 

There  are  inherent  risks  that  should  be  considered  before  any  corrective  action  is 
taken. 

Corrective  action  may  include  the  following: 

•  Taking  remedial  action  to  repair  defective  work  products  or  services 

•  Changing  the  plan  for  performing  the  process 

•  Adjusting  resources,  including  people,  tools,  and  other  resources 

•  Negotiating  changes  to  the  established  commitments 

•  Securing  change  to  the  requirements  and  objectives  that  have  to  be  satisfied 

•  Terminating  the  effort 

7.  Track  corrective  action  to  closure. 

GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  against  its 
process  description,  standards,  and  procedures,  and  address 
noncompliance. 


The  purpose  of  this  generic  practice  is  to  provide  credible  assurance 
that  the  process  is  implemented  as  planned  and  adheres  to  its  process 
description,  standards,  and  procedures.  This  generic  practice  is 
implemented,  in  part,  by  evaluating  selected  work  products  of  the 
process.  (See  the  definition  of  objectively  evaluate  in  the  glossary.) 
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Refer  to  the  Process  and  Product  Quality  Assurance  process  area  for 
more  information  about  objectively  evaluating  adherence. 

People  not  directly  responsible  for  managing  or  performing  the  activities 
of  the  process  typically  evaluate  adherence.  In  many  cases,  adherence 
is  evaluated  by  people  within  the  organization,  but  external  to  the 
process  or  project,  or  by  people  external  to  the  organization.  As  a 
result,  credible  assurance  of  adherence  can  be  provided  even  during 
times  when  the  process  is  under  stress  (e.g.,  when  the  effort  is  behind 
schedule  or  over  budget). 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  process  with 
higher  level  management  and  resolve  issues. 


The  purpose  of  this  generic  practice  is  to  provide  higher  level 
management  with  the  appropriate  visibility  into  the  process. 

Higher  level  management  includes  those  levels  of  management  in  the 
organization  above  the  immediate  level  of  management  responsible  for 
the  process.  In  particular,  higher  level  management  includes  senior 
management.  These  reviews  are  for  managers  who  provide  the  policy 
and  overall  guidance  for  the  process,  and  not  for  those  who  perform  the 
direct  day-to-day  monitoring  and  controlling  of  the  process. 

Different  managers  have  different  needs  for  information  about  the 
process.  These  reviews  help  ensure  that  informed  decisions  on  the 
planning  and  performing  of  the  process  can  be  made.  Therefore,  these 
reviews  are  expected  to  be  both  periodic  and  event  driven. 


GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  a 
description  of  the  process  that  is  tailored  from  the  organization’s  set  of 
standard  processes  to  address  the  needs  of  a  specific  instantiation.  The 
organization  should  have  standard  processes  that  cover  the  process 
area,  as  well  as  have  guidelines  for  tailoring  these  standard  processes 
to  meet  the  needs  of  a  project  or  organizational  function.  With  a  defined 
process,  variability  in  how  the  processes  are  performed  across  the 
organization  is  reduced  and  process  assets,  data,  and  learning  can  be 
effectively  shared. 
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Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  on  establishing  and  maintaining  the  project’s  defined 
process. 

The  descriptions  of  the  defined  processes  provide  the  basis  for 
planning,  performing,  and  managing  the  activities,  work  products,  and 
services  associated  with  the  process. 

Subpractices 

1 .  Select  from  the  organization’s  set  of  standard  processes  those 
processes  that  cover  the  process  area  and  best  meet  the  needs  of 
the  project  or  organizational  function. 

2.  Establish  the  defined  process  by  tailoring  the  selected  processes 
according  to  the  organization’s  tailoring  guidelines. 

3.  Ensure  that  the  organization’s  process  objectives  are  appropriately 
addressed  in  the  defined  process. 

4.  Document  the  defined  process  and  the  records  of  the  tailoring. 

5.  Revise  the  description  of  the  defined  process  as  necessary. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process 
assets. 


The  purpose  of  this  generic  practice  is  to  collect  information  and 
artifacts  derived  from  planning  and  performing  the  process.  This  generic 
practice  is  performed  so  that  the  information  and  artifacts  can  be 
included  in  the  organizational  process  assets  and  made  available  to 
those  who  are  (or  who  will  be)  planning  and  performing  the  same  or 
similar  processes.  The  information  and  artifacts  are  stored  in  the 
organization’s  measurement  repository  and  the  organization’s  process 
asset  library. 


Examples  of  relevant  information  include  the  effort  expended  for  the  various  activities, 
defects  injected  or  removed  in  a  particular  activity,  and  lessons  learned. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  measurement  repository  and 
process  asset  library  and  for  more  information  about  the  work  products, 
measures,  and  improvement  information  that  are  incorporated  into  the 
organizational  process  assets. 
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Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  on  contributing  work  products,  measures,  and  documented 
experiences  to  the  organizational  process  assets. 

Subpractices 

1 .  Store  process  and  product  measures  in  the  organization’s 
measurement  repository. 

The  process  and  product  measures  are  primarily  those  that  are  defined  in  the 
common  set  of  measures  for  the  organization’s  set  of  standard  processes. 

2.  Submit  documentation  for  inclusion  in  the  organization’s  process 
asset  library. 

3.  Document  lessons  learned  from  the  process  for  inclusion  in  the 
organization’s  process  asset  library. 

4.  Propose  improvements  to  the  organizational  process  assets. 


GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  process, 
which  address  quality  and  process  performance,  based  on 
customer  needs  and  business  objectives. 


The  purpose  of  this  generic  practice  is  to  determine  and  obtain 
agreement  from  relevant  stakeholders  about  specific  quantitative 
objectives  for  the  process.  These  quantitative  objectives  can  be 
expressed  in  terms  of  product  quality,  service  quality,  and  process 
performance. 

Refer  to  the  Quantitative  Project  Management  process  area  for 
information  on  how  quantitative  objectives  are  set  for  subprocesses  of 
the  project’s  defined  process. 

The  quantitative  objectives  may  be  specific  to  the  process  or  they  may 
be  defined  for  a  broader  scope  (e.g.,  for  a  set  of  processes).  In  the 
latter  case,  these  quantitative  objectives  may  be  allocated  to  some  of 
the  included  processes. 

These  quantitative  objectives  are  criteria  used  to  judge  whether  the 
products,  services,  and  process  performance  will  satisfy  the  customers, 
end  users,  organization  management,  and  process  implementers. 
These  quantitative  objectives  go  beyond  the  traditional  end-product 
objectives.  They  also  cover  intermediate  objectives  that  are  used  to 
manage  the  achievement  of  the  objectives  over  time.  They  reflect,  in 
part,  the  demonstrated  performance  of  the  organization’s  set  of 
standard  processes.  These  quantitative  objectives  should  be  set  to 
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values  that  are  likely  to  be  achieved  when  the  processes  involved  are 
stable  and  within  their  natural  bounds. 

Subpractices 

1 .  Establish  the  quantitative  objectives  that  pertain  to  the  process. 

2.  Allocate  the  quantitative  objectives  to  the  process  or  its 
subprocesses. 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  process  to  achieve  the  established 
quantitative  quality  and  process-performance  objectives. 

The  purpose  of  this  generic  practice  is  to  stabilize  the  performance  of 
one  or  more  subprocesses  of  the  defined  process,  which  are  critical 
contributors  to  overall  performance,  using  appropriate  statistical  and 
other  quantitative  techniques.  Stabilizing  selected  subprocesses 
supports  predicting  the  ability  of  the  process  to  achieve  the  established 
quantitative  quality  and  process-performance  objectives. 

Refer  to  the  Quantitative  Project  Management  process  area  for 
information  on  selecting  subprocesses  for  statistical  management, 
monitoring  performance  of  subprocesses,  and  other  aspects  of 
stabilizing  subprocess  performance. 

A  stable  subprocess  shows  no  significant  indication  of  special  causes  of 
process  variation.  Stable  subprocesses  are  predictable  within  the  limits 
established  by  the  natural  bounds  of  the  subprocess.  Variations  in  the 
stable  subprocess  are  due  to  a  constant  system  of  chance  causes,  and 
the  magnitude  of  the  variations  can  be  small  or  large. 

Predicting  the  ability  of  the  process  to  achieve  the  established 
quantitative  objectives  requires  a  quantitative  understanding  of  the 
contributions  of  the  subprocesses  that  are  critical  to  achieving  these 
objectives  and  establishing  and  managing  against  interim  quantitative 
objectives  over  time. 

Selected  process  and  product  measures  are  incorporated  into  the 
organization’s  measurement  repository  to  support  process-performance 
analysis  and  future  fact-based  decision  making. 

Subpractices 

1 .  Statistically  manage  the  performance  of  one  or  more  subprocesses 
that  are  critical  contributors  to  the  overall  performance  of  the 
process. 
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2.  Predict  the  ability  of  the  process  to  achieve  its  established 
quantitative  objectives  considering  the  performance  of  the 
statistically  managed  subprocesses. 

3.  Incorporate  selected  process-performance  measurements  into  the 
organization’s  process-performance  baselines. 


Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  process  in  fulfilling  the 
relevant  business  objectives  of  the  organization. 


The  purpose  of  this  generic  practice  is  to  select  and  systematically 
deploy  process  and  technology  improvements  that  contribute  to 
meeting  established  quality  and  process-performance  objectives. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  information  about  selecting  and  deploying  incremental  and 
innovative  improvements  that  measurably  improve  the  organization's 
processes  and  technologies. 

Optimizing  the  processes  that  are  agile  and  innovative  depends  on  the 
participation  of  an  empowered  workforce  aligned  with  the  business 
values  and  objectives  of  the  organization.  The  organization’s  ability  to 
rapidly  respond  to  changes  and  opportunities  is  enhanced  by  finding 
ways  to  accelerate  and  share  learning.  Improvement  of  the  processes  is 
inherently  part  of  everybody’s  role,  resulting  in  a  cycle  of  continual 
improvement. 

Subpractices 

1.  Establish  and  maintain  quantitative  process  improvement 
objectives  that  support  the  organization’s  business  objectives. 

The  quantitative  process  improvement  objectives  may  be  specific  to  the  individual 
process  or  they  may  be  defined  for  a  broader  scope  (i.e.,  for  a  set  of  processes), 
with  the  individual  processes  contributing  to  achieving  these  objectives. 

Objectives  that  are  specific  to  the  individual  process  are  typically  allocated  from 
quantitative  objectives  established  for  a  broader  scope. 

These  process  improvement  objectives  are  primarily  derived  from  the 
organization’s  business  objectives  and  from  a  detailed  understanding  of  process 
capability.  These  objectives  are  the  criteria  used  to  judge  whether  the  process 
performance  is  quantitatively  improving  the  organization’s  ability  to  meet  its 
business  objectives.  These  process  improvement  objectives  are  often  set  to 
values  beyond  the  current  process  performance,  and  both  incremental  and 
innovative  technological  improvements  may  be  needed  to  achieve  these 
objectives.  These  objectives  may  also  be  revised  frequently  to  continue  to  drive 
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the  improvement  of  the  process  (i.e.,  when  an  objective  is  achieved,  it  may  be  set 
to  a  new  value  that  is  again  beyond  the  new  process  performance). 

These  process  improvement  objectives  may  be  the  same  as,  or  a  refinement  of, 
the  objectives  established  in  the  “Establish  Quantitative  Objectives  for  the 
Process”  generic  practice,  as  long  as  they  can  serve  as  both  drivers  and  criteria 
for  successful  process  improvement. 

2.  Identify  process  improvements  that  would  result  in  measurable 
improvements  to  process  performance. 

Process  improvements  include  both  incremental  changes  and  innovative 
technological  improvements.  The  innovative  technological  improvements  are 
typically  pursued  as  efforts  that  are  separately  planned,  performed,  and  managed. 
Piloting  is  often  performed.  These  efforts  often  address  specific  areas  of  the 
processes  that  are  determined  by  analyzing  process  performance  and  identifying 
specific  opportunities  for  significant  measurable  improvement. 

3.  Define  strategies  and  manage  deployment  of  selected  process 
improvements  based  on  the  quantified  expected  benefits,  the 
estimated  costs  and  impacts,  and  the  measured  change  to  process 
performance. 

The  costs  and  benefits  of  these  improvements  are  estimated  quantitatively,  and 
the  actual  costs  and  benefits  are  measured.  Benefits  are  primarily  considered 
relative  to  the  organization’s  quantitative  process  improvement  objectives. 
Improvements  are  made  to  both  the  organization’s  set  of  standard  processes  and 
the  defined  processes. 

Managing  deployment  of  the  process  improvements  includes  piloting  changes  and 
implementing  adjustments  where  appropriate,  addressing  potential  and  real 
barriers  to  deployment,  minimizing  disruption  to  ongoing  efforts,  and  managing 
risks. 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  process. 


The  purpose  of  this  generic  practice  is  to  analyze  defects  and  other 
problems  that  were  encountered  in  a  quantitatively  managed  process, 
to  correct  the  root  causes  of  these  types  of  defects  and  problems,  and 
to  prevent  these  defects  and  problems  from  occurring  in  the  future. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  identifying  and  correcting  root  causes  of  selected 
defects.  Even  though  the  Causal  Analysis  and  Resolution  process  area 
has  a  project  context,  it  can  be  applied  to  processes  in  other  contexts 
as  well. 
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Root  cause  analysis  can  be  applied  beneficially  to  processes  that  are 
not  quantitatively  managed.  However,  the  focus  of  this  generic  practice 
is  to  act  on  a  quantitatively  managed  process,  though  the  final  root 
causes  may  be  found  outside  of  that  process. 


Applying  Generic  Practices 


This  section  helps  you  to  develop  a  better  understanding  of  the  generic 
practices  and  provides  information  for  interpreting  and  applying  the 
generic  practices  in  your  organization. 

Generic  practices  are  components  that  are  common  to  all  process 
areas.  Think  of  generic  practices  as  reminders.  They  serve  the  purpose 
of  reminding  you  to  do  things  right,  and  are  expected  model 
components. 

For  example,  when  you  are  achieving  the  specific  goals  of  the  Project 
Planning  process  area,  you  are  establishing  and  maintaining  a  plan  that 
defines  project  activities.  One  of  the  generic  practices  that  applies  to  the 
Project  Planning  process  area  is  “Establish  and  maintain  the  plan  for 
performing  the  project  planning  process”  (GP  2.2).  When  applied  to  this 
process  area,  this  generic  practice  reminds  you  to  plan  the  activities 
involved  in  creating  the  plan  for  the  project. 

When  you  are  satisfying  the  specific  goals  of  the  Organizational 
Training  process  area,  you  are  developing  the  skills  and  knowledge  of 
people  in  your  project  and  organization  so  that  they  can  perform  their 
roles  effectively  and  efficiently.  When  applying  the  same  generic 
practice  (GP  2.2)  to  the  Organizational  Training  process  area,  this 
generic  practice  reminds  you  to  plan  the  activities  involved  in 
developing  the  skills  and  knowledge  of  people  in  the  organization. 


Process  Areas  That  Support  Generic  Practices 


While  generic  goals  and  generic  practices  are  the  model  components 
that  directly  address  the  institutionalization  of  a  process  across  the 
organization,  many  process  areas  likewise  address  institutionalization 
by  supporting  the  implementation  of  the  generic  practices.  Knowing 
these  relationships  will  help  you  effectively  implement  the  generic 
practices. 

Such  process  areas  contain  one  or  more  specific  practices  that  when 
implemented  may  also  fully  implement  a  generic  practice  or  generate  a 
work  product  that  is  used  in  the  implementation  of  a  generic  practice. 


94 


Generic  Goals  and  Generic  Practices 


CMMI  for  Development 
Version  1.2 


An  example  is  the  Configuration  Management  process  area  and  GP 
2.6,  “Place  designated  work  products  of  the  process  under  appropriate 
levels  of  control.”  To  implement  the  generic  practice  for  one  or  more 
process  areas,  you  might  choose  to  implement  the  Configuration 
Management  process  area,  all  or  in  part,  to  implement  the  generic 
practice. 

Another  example  is  the  Organizational  Process  Definition  process  area 
and  GP  3.1,  “Establish  and  maintain  the  description  of  a  defined 
process.”  To  implement  this  generic  practice  for  one  or  more  process 
areas,  you  should  first  implement  the  Organizational  Process  Definition 
process  area,  all  or  in  part,  to  establish  the  organizational  process 
assets  that  are  needed  to  implement  the  generic  practice. 

Table  6.2  describes  (1 )  the  process  areas  that  support  the 
implementation  of  generic  practices,  and  (2)  the  recursive  relationships 
between  generic  practices  and  their  closely  related  process  areas.  Both 
types  of  relationships  are  important  to  remember  during  process 
improvement  to  take  advantage  of  the  natural  synergies  that  exist 
between  the  generic  practices  and  their  related  process  areas. 


Table  6.2  Generic  Practice  and  Process  Area  Relationships 


Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP2.2 

Plan  the  Process 

Project  Planning:  The  project  planning 
process  can  implement  GP  2.2  in  full  for 
all  project-related  process  areas  (except 
for  Project  Planning  itself). 

GP  2.2  applied  to  the  project  planning 
process  can  be  characterized  as  “plan 
the  plan”  and  covers  planning  project 
planning  activities. 

GP  2.3 

Provide 

Resources 

GP  2.4 

Assign 

Responsibility 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.4, 

“Plan  for  necessary  resources  to 
perform  the  project,”  supports  the 
implementation  of  GP  2.3  and  GP  2.4 
for  all  project-related  process  areas 
(except  perhaps  initially  for  Project 
Planning  itself)  by  identifying  needed 
processes,  roles,  and  responsibilities  to 
ensure  the  proper  staffing,  facilities, 
equipment,  and  other  assets  needed  by 
the  project  are  secured. 

14  When  the  relationship  between  a  generic  practice  and  a  process  area  is  less  direct,  the  risk  of  confusion  is 
reduced;  therefore,  we  do  not  describe  all  recursive  relationships  in  the  table  (e.g.,  for  generic  practices  2.3, 
2.4,  and  2.10). 
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Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP2.5 

Train  People 

Organizational  Training:  The 

organizational  training  process  supports 
the  implementation  of  GP  2.5  as  applied 
to  all  process  areas  by  making  the 
training  that  addresses  strategic  or 
organization-wide  training  needs 
available  to  those  who  will  perform  or 
support  the  process. 

GP  2.5  applied  to  the  organizational 
training  process  area  covers  training  for 
performing  the  organizational  training 
activities,  which  addresses  the  skills 
required  to  manage,  create,  and 
accomplish  the  training. 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.5, 

“Plan  for  knowledge  and  skills  needed  to 
perform  the  project,”  together  with  the 
organizational  training  process,  supports 
the  implementation  of  GP  2.5  in  full  for 
all  project-related  process  areas. 

GP  2.6 

Manage 

Configurations 

Configuration  Management:  The 

configuration  management  process  can 
implement  GP  2.6  in  full  for  all  project- 
related  process  areas  as  well  as  some 
of  the  organizational  process  areas. 

GP  2.6  applied  to  the  configuration 
management  process  covers  change 
and  version  control  for  the  work 
products  produced  by  configuration 
management  activities. 

GP  2.7 

Identify  and 
Involve  Relevant 
Stakeholders 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.6, 

“Plan  Stakeholder  Involvement,”  can 
implement  the  stakeholder  identification 
part  (first  two  subpractices)  of  GP  2.7  in 
full  for  all  project-related  process  areas. 

GP  2.7  applied  to  the  project  planning 
process  covers  the  involvement  of 
relevant  stakeholders  in  project  planning 
activities. 

GP  2.7  applied  to  the  project  monitoring 
and  control  process  covers  the 

involvement  of  relevant  stakeholders  in 


Project  Monitoring  and  Control:  The  project  monitoring  and  control  activities, 
part  of  the  project  monitoring  and  control 

process  that  implements  Project  GP  2.7  applied  to  the  integrated  project 

Monitoring  and  Control  SP  1.5,  “Monitor  management  process  covers  the 
Stakeholder  Involvement,”  can  aid  in  involvement  of  relevant  stakeholders  in 
implementing  the  third  subpractice  of  integrated  project  management 
GP  2.7  for  all  project-related  process  activities, 
areas. 

Integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  2.1, 

“Manage  Stakeholder  Involvement,”  can 
aid  in  implementing  the  third  subpractice 
of  GP  2.7  for  all  project-related  process 
areas. 
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Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP  2.8 

Monitor  and 
Control  the 
Process 

Project  Monitoring  and  Control:  The 

project  monitoring  and  control  process 
can  implement  GP  2.8  in  full  for  all 
project-related  process  areas. 

GP  2.8  applied  to  the  project  monitoring 
and  control  process  covers  the 
monitoring  and  controlling  of  the 
project’s  monitor  and  control  activities. 

Measurement  and  Analysis:  For  all 

processes,  not  just  project-related 
processes,  the  Measurement  and 

Analysis  process  area  provides  general 
guidance  about  measuring,  analyzing, 
and  recording  information  that  can  be 
used  in  establishing  measures  for 
monitoring  actual  performance  of  the 
process. 

GP  2.9 

Objectively 

Evaluate 

Adherence 

Process  and  Product  Quality 
Assurance:  The  process  and  product 
quality  assurance  process  can 
implement  GP  2.9  in  full  for  all  process 
areas  (except  perhaps  for  Process  and 
Product  Quality  Assurance  itself). 

GP  2.9  applied  to  the  process  and 
product  quality  assurance  process 
covers  the  objective  evaluation  of  quality 
assurance  activities. 

GP  2.10 

Review  Status 
with  Higher  Level 
Management 

Project  Monitoring  and  Control:  The 

part  of  the  project  monitoring  and  control 
process  that  implements  Project 
Monitoring  and  Control  SP  1.6,  “Conduct 
Progress  Reviews,”  and  SP  1.7, 

“Conduct  Milestone  Reviews,”  supports 
the  implementation  of  GP  2. 1 0  for  all 
project-related  process  areas,  perhaps 
in  full,  depending  on  higher  level 
management  involvement  in  these 
reviews. 

GP  3.1 

Establish  a 
Defined  Process 

Integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  1.1, 
“Establish  and  maintain  the  project’s 
defined  process  from  project  startup 
through  the  life  of  the  project,”  can 
implement  GP  3.1  in  full  for  all  project- 
related  process  areas. 

GP  3.1  applied  to  the  integrated  project 
management  process  covers 
establishing  defined  processes  for 
integrated  project  management 
activities. 

Organizational  Process  Definition: 

For  all  processes,  not  just  project- 
related  processes,  the  organizational 
process  definition  process  establishes 
the  organizational  process  assets 
needed  to  implement  GP  3.1. 
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Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP  3.2 

Collect 

Improvement 

Information 

Integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  1.6, 
“Contribute  work  products,  measures, 
and  documented  experiences  to  the 
organizational  process  assets,”  can 
implement  GP  3.2  in  part  or  full  for  all 
project-related  process  areas. 

GP  3.2  applied  to  the  integrated  project 
management  process  covers  collecting 
improvement  information  derived  from 
planning  and  performing  integrated 
project  management  activities. 

Organizational  Process  Focus:  The 

part  of  the  organizational  process  focus 
process  that  implements  Organizational 
Process  Focus  SP  3.4,  “Incorporate 
process-related  work  products, 
measures,  and  improvement  information 
derived  from  planning  and  performing 
the  process  into  the  organizational 
process  assets,”  can  implement  GP  3.2 
in  part  or  full  for  all  process  areas. 

Organizational  Process  Definition: 

For  all  processes,  the  organizational 
process  definition  process  establishes 
the  organizational  process  assets 
needed  to  implement  GP  3.2. 

GP  4.1 
Establish 
Quantitative 
Objectives  for 
the  Process 


Quantitative  Project  Management: 

The  part  of  the  quantitative  project 
management  process  that  implements 
Quantitative  Project  Management  SP 
1.1,  “Establish  and  maintain  the  project’s 
quality  and  process-performance 
objectives,”  supports  the  implementation 
of  GP  4.1  for  all  project-related  process 
areas  by  providing  objectives  from  which 
the  objectives  for  each  particular 
process  can  be  derived.  If  these 
objectives  become  established  as  part 
of  implementing  subpractices  5  and  8  of 
Quantitative  Project  Management  SP 
1.1,  then  the  quantitative  project 
management  process  implements  GP 
4.1  in  full. 


GP  4.1  applied  to  the  quantitative 
project  management  process  covers 
establishing  quantitative  objectives  for 
quantitative  project  management 
activities. 

GP  4.1  applied  to  the  organizational 
process  performance  process  covers 
establishing  quantitative  objectives  for 
organizational  process-performance 
activities. 


Organizational  Process 
PerformanceiThe  part  of  the 
organizational  process  performance 
process  that  implements  Organizational 
Process  Performance  SP  1.3,  “Establish 
and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the 
organization,”  supports  the 
implementation  of  GP  4.1  for  all  process 
areas. 
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Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP  4.2 

Stabilize 

Subprocess 

Performance 

Quantitative  Project  Management: 

The  part  of  the  quantitative  project 
management  process  that  implements 
Quantitative  Project  Management  SG  2, 
“Statistically  Manage  Subprocess 
Performance,”  can  implement  GP  4.2  in 
full  for  all  project-related  process  areas 
to  which  a  statistically  managed 
subprocess  can  be  mapped. 

GP  4.2  applied  to  the  quantitative 
project  management  process  covers  the 
stabilization  of  selected  subprocesses 
within  quantitative  project  management 
activities. 

Organizational  Process  Performance: 

For  all  processes,  not  just  project- 
related  processes,  the  organizational 
process  performance  process 
establishes  organizational  process 
assets  that  may  be  needed  to  implement 
GP  4.2. 

GP  5.1 

Ensure 

Continuous 

Process 

Improvement 

Organizational  Innovation  and 
Deployment:  The  organizational 
innovation  and  deployment  process  can 
implement  GP  5.1  in  full  for  all  process 
areas  providing  that  quality  and  process- 
performance  objectives  for  the 
organization  have  been  defined.  (The 
latter  would  be  the  case,  say,  if  the 
Organizational  Process  Performance 
process  area  has  been  implemented.) 

GP  5.1  applied  to  the  organizational 
innovation  and  deployment  process 
covers  ensuring  continuous  process 
improvement  of  organizational 
innovation  and  deployment  activities. 

GP  5.2 

Correct  Root 
Causes  of 
Problems 

Causal  Analysis  and  Resolution:  The 

causal  analysis  and  resolution  process 
can  implement  GP  5.2  in  full  for  all 
project-related  process  areas. 

GP  5.2  applied  to  the  causal  analysis 
and  resolution  process  covers 
identifying  root  causes  of  defects  and 
other  problems  in  causal  analysis  and 
resolution  activities. 

Given  the  dependencies  that  generic  practices  have  on  these  process 
areas,  and  given  the  more  “holistic”  view  that  many  of  these  process 
areas  provide,  these  process  areas  are  often  implemented  early,  in 
whole  or  in  part,  before  or  concurrent  with  implementing  the  associated 
generic  practices. 

There  are  also  a  few  situations  where  the  result  of  applying  a  generic 
practice  to  a  particular  process  area  would  seem  to  make  a  whole 
process  area  redundant,  but,  in  fact,  it  does  not.  It  may  be  natural  to 
think  that  applying  GP  3.1 ,  Establish  a  Defined  Process,  to  the  Project 
Planning  and  Project  Monitoring  and  Control  process  areas  gives  the 
same  effect  as  the  first  specific  goal  of  Integrated  Project  Management, 
“The  project  is  conducted  using  a  defined  process  that  is  tailored  from 
the  organization’s  set  of  standard  processes.” 
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Although  it  is  true  that  there  is  some  overlap,  the  application  of  the 
generic  practice  to  these  two  process  areas  provides  defined  processes 
covering  project  planning  and  project  monitoring  and  control  activities. 
These  defined  processes  do  not  necessarily  cover  support  activities 
(such  as  configuration  management),  other  project  management 
processes  (such  as  supplier  agreement  management),  or  the 
engineering  processes.  In  contrast,  the  project’s  defined  process, 
provided  by  the  Integrated  Project  Management  process  area,  covers 
all  appropriate  project  management,  engineering,  and  support 
processes. 
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CAUSAL  ANALYSIS  AND  RESOLUTION 

A  Support  Process  Area  at  Maturity  Level  5 


Purpose 


The  purpose  of  Causal  Analysis  and  Resolution  (CAR)  is  to  identify 
causes  of  defects  and  other  problems  and  take  action  to  prevent  them 
from  occurring  in  the  future. 


Introductory  Notes 


The  Causal  Analysis  and  Resolution  process  area  involves  the 
following: 

•  Identifying  and  analyzing  causes  of  defects  and  other  problems 

•  Taking  specific  actions  to  remove  the  causes  and  prevent  the 
occurrence  of  those  types  of  defects  and  problems  in  the  future 

Causal  analysis  and  resolution  improves  quality  and  productivity  by 
preventing  the  introduction  of  defects  into  a  product.  Reliance  on 
detecting  defects  after  they  have  been  introduced  is  not  cost  effective.  It 
is  more  effective  to  prevent  defects  from  being  introduced  by  integrating 
causal  analysis  and  resolution  activities  into  each  phase  of  the  project. 

Since  defects  and  problems  may  have  been  previously  encountered  on 
other  projects  or  in  earlier  phases  or  tasks  of  the  current  project,  causal 
analysis  and  resolution  activities  are  a  mechanism  for  communicating 
lessons  learned  among  projects. 

The  types  of  defects  and  other  problems  encountered  are  analyzed  to 
identify  any  trends.  Based  on  an  understanding  of  the  defined  process 
and  how  it  is  implemented,  the  root  causes  of  the  defects  and  the  future 
implications  of  the  defects  are  determined. 

Causal  analysis  may  also  be  performed  on  problems  unrelated  to 
defects.  For  example,  causal  analysis  may  be  used  to  improve  quality 
attributes  such  as  cycle  time.  Improvement  proposals,  simulations, 
dynamic  systems  models,  engineering  analyses,  new  business 
directives,  or  other  items  may  initiate  such  analysis. 

When  it  is  impractical  to  perform  causal  analysis  on  all  defects,  defect 
targets  are  selected  by  tradeoffs  on  estimated  investments  and 
estimated  returns  of  quality,  productivity  and  cycle  time. 
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A  measurement  process  should  already  be  in  place.  The  defined 
measures  can  be  used,  though  in  some  instances  new  measures  may 
be  needed  to  analyze  the  effects  of  the  process  change. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

Causal  Analysis  and  Resolution  activities  provide  a  mechanism  for 
projects  to  evaluate  their  processes  at  the  local  level  and  look  for 
improvements  that  can  be  implemented. 

When  improvements  are  judged  to  be  effective,  the  information  is 
extended  to  the  organizational  level. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  improving  organizational  level  processes 
through  proposed  improvements  and  action  proposals. 

The  informative  material  in  this  process  area  is  written  with  the 
assumption  that  the  specific  practices  are  applied  to  a  quantitatively 
managed  process.  The  specific  practices  of  this  process  area  may  be 
applicable,  but  with  reduced  value,  if  this  assumption  is  not  met. 

See  the  definitions  of  “stable  process”  and  “common  cause  of  process 
variation”  in  the  glossary. 


Related  Process  Areas 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  analysis  of  process  performance  and  the  creation 
of  process  capability  measures  for  selected  project  processes. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  the  selection  and  deployment  of 
improvements  to  organizational  processes  and  technologies. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 
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Specific  Goal  and  Practice  Summary 

SG  1  Determine  Causes  of  Defects 

SP  1 .1  Select  Defect  Data  for  Analysis 
SP  1 .2  Analyze  Causes 
SG  2  Address  Causes  of  Defects 

SP  2.1  Implement  the  Action  Proposals 
SP  2.2  Evaluate  the  Effect  of  Changes 
SP  2.3  Record  Data 


Specific  Practices  by  Goal 


SG  1  Determine  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are  systematically  determined. 

A  root  cause  is  a  source  of  a  defect  such  that,  if  it  is  removed,  the 
defect  is  decreased  or  removed. 

SP  1 .1  Select  Defect  Data  for  Analysis 

Select  the  defects  and  other  problems  for  analysis. 

Typical  Work  Products 

1 .  Defect  and  problem  data  selected  for  further  analysis 
Subpractices 

1 .  Gather  relevant  defect  or  problem  data. 

Examples  of  relevant  defect  data  may  include  the  following: 

i  •  Defects  reported  by  the  customer 
|  •  Defects  reported  by  end  users 
i  •  Defects  found  in  peer  reviews 
:  •  Defects  found  in  testing 

Examples  of  relevant  problem  data  may  include  the  following: 

|  •  Project  management  problem  reports  requiring  corrective  action 
j  •  Process  capability  problems 
:  •  Process  duration  measurements 

|  •  Earned  value  measurements  by  process  (e.g.,  cost  performance  index) 

•  Resource  throughput,  utilization,  or  response  time  measurements 


Refer  to  the  Verification  process  area  for  more  information  about 
work  product  verification. 
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Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  statistical  management. 

2.  Determine  which  defects  and  other  problems  will  be  analyzed 
further. 

When  determining  which  defects  to  analyze  further,  consider  the  impact  of  the 
defects,  their  frequency  of  occurrence,  the  similarity  between  defects,  the  cost  of 
analysis,  the  time  and  resources  needed,  the  safety  considerations,  etc. 


Examples  of  methods  for  selecting  defects  and  other  problems  include  the 
following: 

•  Pareto  analysis 

•  Histograms 

•  Process  capability  analysis 


SP  1.2  Analyze  Causes 

Perform  causal  analysis  of  selected  defects  and  other  problems 
and  propose  actions  to  address  them. 


The  purpose  of  this  analysis  is  to  develop  solutions  to  the  identified 
problems  by  analyzing  the  relevant  data  and  producing  action  proposals 
for  implementation. 

Typical  Work  Products 
1 .  Action  proposal 

Subpractices 

1 .  Conduct  causal  analysis  with  the  people  who  are  responsible  for 
performing  the  task. 

Causal  analysis  is  performed,  typically  in  meetings,  with  those  people  who  have 
an  understanding  of  the  selected  defect  or  problem  under  study.  The  people  who 
have  the  best  understanding  of  the  selected  defect  are  typically  those  responsible 
for  performing  the  task. 


Examples  of  when  to  perform  causal  analysis  include  the  following: 

•  When  a  stable  process  does  not  meet  its  specified  quality  and  process- 
performance  objectives 

•  During  the  task,  if  and  when  problems  warrant  a  causal  analysis  meeting 

•  When  a  work  product  exhibits  an  unexpected  deviation  from  its  requirements 
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2.  Analyze  selected  defects  and  other  problems  to  determine  their 
root  causes. 

Depending  on  the  type  and  number  of  defects,  it  may  make  sense  to  first  group 
the  defects  before  identifying  their  root  causes. 

Examples  of  methods  to  determine  root  causes  include  the  following: 

:  •  Cause-and-effect  (fishbone)  diagrams 
:  •  Check  sheets 

3.  Group  the  selected  defects  and  other  problems  based  on  their  root 
causes. 

:  Examples  of  cause  groups,  or  categories,  include  the  following: 

|  •  Inadequate  training 

i  •  Breakdown  of  communications 

I  •  Not  accounting  for  all  details  of  a  task 

|  •  Making  mistakes  in  manual  procedures  (e.g.,  typing) 

•  Process  deficiency 

4.  Propose  and  document  actions  that  need  to  be  taken  to  prevent 
the  future  occurrence  of  similar  defects  or  other  problems. 

Examples  of  proposed  actions  include  changes  to  the  following: 

i  •  The  process  in  question 
|  •  Training 
|  •  Tools 
:  •  Methods 
i  •  Communications 
:  •  Work  products 

■  Examples  of  specific  actions  include  the  following: 

:  •  Providing  training  in  common  problems  and  techniques  for  preventing  them 
i  •  Changing  a  process  so  that  error-prone  steps  do  not  occur 
|  •  Automating  all  or  part  of  a  process 
:  •  Reordering  process  activities 

:  •  Adding  process  steps  to  prevent  defects,  such  as  task  kickoff  meetings  to  review 
common  defects  and  actions  to  prevent  them 
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An  action  proposal  usually  documents  the  following: 

•  Originator  of  the  action  proposal 

•  Description  of  the  problem 

•  Description  of  the  defect  cause 

•  Defect  cause  category 

•  Phase  when  the  problem  was  introduced 

•  Phase  when  the  defect  was  identified 

•  Description  of  the  action  proposal 

•  Action  proposal  category 

SG  2  Address  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are  systematically  addressed 
to  prevent  their  future  occurrence. 

Projects  operating  according  to  a  well-defined  process  will 
systematically  analyze  the  operation  where  problems  still  occur  and 
implement  process  changes  to  eliminate  root  causes  of  selected 
problems. 

SP  2.1  Implement  the  Action  Proposals 

Implement  the  selected  action  proposals  that  were  developed  in 
causal  analysis. 

Action  proposals  describe  the  tasks  necessary  to  remove  the  root 
causes  of  the  analyzed  defects  or  problems  and  avoid  their 
reoccurrence. 

Only  changes  that  prove  to  be  of  value  should  be  considered  for  broad 
implementation. 

Typical  Work  Products 

1 .  Action  proposals  selected  for  implementation 

2.  Improvement  proposals 

Subpractices 

1 .  Analyze  the  action  proposals  and  determine  their  priorities. 

Criteria  for  prioritizing  action  proposals  include  the  following: 

•  Implications  of  not  addressing  the  defects 

•  Cost  to  implement  process  improvements  to  prevent  the  defects 

•  Expected  impact  on  quality 

2.  Select  the  action  proposals  that  will  be  implemented. 


106 


Causal  Analysis  and  Resolution  (CAR) 


CMMI  for  Development 
Version  1.2 

3.  Create  action  items  for  implementing  the  action  proposals. 

Examples  of  information  provided  in  an  action  item  include  the  following: 

|  •  Person  responsible  for  implementing  it 

:  •  Description  of  the  areas  affected  by  it 

:  •  People  who  are  to  be  kept  informed  of  its  status 

;  •  Next  date  that  status  will  be  reviewed 

|  •  Rationale  for  key  decisions 

:  •  Description  of  implementation  actions 

i  •  Time  and  cost  for  identifying  the  defect  and  correcting  it 

•  Estimated  cost  of  not  fixing  the  problem 

To  implement  the  action  proposals,  the  following  tasks  must  be  done: 

•  Make  assignments 

•  Coordinate  the  persons  doing  the  work 

•  Review  the  results 

•  Track  the  action  items  to  closure 

Experiments  may  be  conducted  for  particularly  complex  changes. 

:  Examples  of  experiments  include  the  following: 

:  •  Using  a  temporarily  modified  process 

•  Using  a  new  tool 

Action  items  may  be  assigned  to  members  of  the  causal  analysis  team,  members 
of  the  project  team,  or  other  members  of  the  organization. 

4.  Identify  and  remove  similar  defects  that  may  exist  in  other 
processes  and  work  products. 

5.  Identify  and  document  improvement  proposals  for  the 
organization’s  set  of  standard  processes. 

Refer  to  the  Organizational  Innovation  and  Deployment  process 
area  for  more  information  about  the  selection  and  deployment  of 
improvement  proposals  for  the  organization’s  set  of  standard 
processes. 

SP  2.2  Evaluate  the  Effect  of  Changes 

Evaluate  the  effect  of  changes  on  process  performance. 
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Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  analyzing  process  performance  and  creating  process 
capability  measures  for  selected  processes. 

Once  the  changed  process  is  deployed  across  the  project,  the  effect  of 
the  changes  must  be  checked  to  gather  evidence  that  the  process 
change  has  corrected  the  problem  and  improved  performance. 

Typical  Work  Products 

1 .  Measures  of  performance  and  performance  change 
Subpractices 

1 .  Measure  the  change  in  the  performance  of  the  project's  defined 
process  as  appropriate. 

This  subpractice  determines  whether  the  selected  change  has  positively 
influenced  the  process  performance  and  by  how  much. 


An  example  of  a  change  in  the  performance  of  the  project’s  defined  design 
process  would  be  the  change  in  the  defect  density  of  the  design  documentation, 
as  statistically  measured  through  peer  reviews  before  and  after  the  improvement 
has  been  made.  On  a  statistical  process  control  chart,  this  would  be  represented 
by  a  change  in  the  mean. 


2.  Measure  the  capability  of  the  project's  defined  process  as 
appropriate. 

This  subpractice  determines  whether  the  selected  change  has  positively 
influenced  the  ability  of  the  process  to  meet  its  quality  and  process-performance 
objectives,  as  determined  by  relevant  stakeholders. 


An  example  of  a  change  in  the  capability  of  the  project’s  defined  design  process 
would  be  a  change  in  the  ability  of  the  process  to  stay  within  its  process- 
specification  boundaries.  This  can  be  statistically  measured  by  calculating  the 
range  of  the  defect  density  of  design  documentation,  as  collected  in  peer  reviews 
before  and  after  the  improvement  has  been  made.  On  a  statistical  process  control 
chart,  this  would  be  represented  by  lowered  control  limits. 


SP  2.3  Record  Data 

Record  causal  analysis  and  resolution  data  for  use  across  the 
project  and  organization. 


Data  are  recorded  so  that  other  projects  and  organizations  can  make 
appropriate  process  changes  and  achieve  similar  results. 
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Record  the  following: 

•  Data  on  defects  and  other  problems  that  were  analyzed 

•  Rationale  for  decisions 

•  Action  proposals  from  causal  analysis  meetings 

•  Action  items  resulting  from  action  proposals 

•  Cost  of  the  analysis  and  resolution  activities 

•  Measures  of  changes  to  the  performance  of  the  defined  process 
resulting  from  resolutions 

Typical  Work  Products 

1.  Causal  analysis  and  resolution  records 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1 

Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  causal  analysis  and 
resolution  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  causal  analysis  and  resolution  process. 
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Elaboration: 

This  policy  establishes  organizational  expectations  for  identifying  and 
systematically  addressing  root  causes  of  defects  and  other  problems. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  causal 
analysis  and  resolution  process. 


Elaboration: 

This  plan  for  performing  the  causal  analysis  and  resolution  process  can 
be  included  in  (or  referenced  by)  the  project  plan,  which  is  described  in 
the  Project  Planning  process  area.  This  plan  differs  from  the  action 
proposals  and  associated  action  items  described  in  several  specific 
practices  in  this  process  area.  The  plan  called  for  in  this  generic 
practice  would  address  the  project’s  overall  causal  analysis  and 
resolution  process  (perhaps  tailored  from  a  standard  process 
maintained  by  the  organization).  In  contrast,  the  process  action 
proposals  and  associated  action  items  address  the  activities  needed  to 
remove  a  specific  root  cause  under  study. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  causal  analysis 
and  resolution  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools: 

•  Database  systems 

•  Process  modeling  tools 

•  Statistical  analysis  packages 

•  Tools,  methods,  and  analysis  techniques  (e.g.,  Ishikawa  or  fishbone  diagram, 
Pareto  analysis,  histograms,  process  capability  studies,  or  control  charts) 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  causal  analysis  and  resolution  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  causal  analysis 
and  resolution  process  as  needed. 
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Elaboration: 

Examples  of  training  topics  include  the  following: 

•  Quality  management  methods  (e.g.,  root  cause  analysis) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  causal  analysis  and 
resolution  process  under  appropriate  levels  of  control. 

Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Action  proposals 

i  •  Action  proposals  selected  for  implementation 
•  Causal  analysis  and  resolution  records 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  causal 
analysis  and  resolution  process  as  planned. 

Elaboration: 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

;  •  Conducting  causal  analysis 
•  Assessing  the  action  proposals 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  causal  analysis  and  resolution  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  root  causes  removed 

•  Change  in  quality  or  process  performance  per  instance  of  the  causal  analysis  and 
resolution  process 

•  Schedule  of  activities  for  implementing  a  selected  action  proposal 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  causal  analysis  and 
resolution  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

|  •  Determining  causes  of  defects 
:  •  Addressing  causes  of  defects 

:  Examples  of  work  products  reviewed  include  the  following: 

;  •  Action  proposals  selected  for  implementation 
•  Causal  analysis  and  resolution  records 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  causal  analysis 
and  resolution  process  with  higher  level  management  and 
resolve  issues. 


Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  causal 
analysis  and  resolution  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  causal  analysis  and  resolution  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 
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Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
:  information  include  the  following: 

i  •  Action  proposals 

i  •  Number  of  action  proposals  that  are  open  and  for  how  long 
•  Action  proposal  status  reports 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  causal 
analysis  and  resolution  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  causal  analysis  and  resolution 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  causal  analysis  and 
resolution  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  causal  analysis  and  resolution  process. 
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CONFIGURATION  MANAGEMENT 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Configuration  Management  (CM)  is  to  establish  and 
maintain  the  integrity  of  work  products  using  configuration  identification, 
configuration  control,  configuration  status  accounting,  and  configuration 
audits. 


Introductory  Notes 


The  Configuration  Management  process  area  involves  the  following: 

•  Identifying  the  configuration  of  selected  work  products  that  compose 
the  baselines  at  given  points  in  time 

•  Controlling  changes  to  configuration  items 

•  Building  or  providing  specifications  to  build  work  products  from  the 
configuration  management  system 

•  Maintaining  the  integrity  of  baselines 

•  Providing  accurate  status  and  current  configuration  data  to 
developers,  end  users,  and  customers 

The  work  products  placed  under  configuration  management  include  the 
products  that  are  delivered  to  the  customer,  designated  internal  work 
products,  acquired  products,  tools,  and  other  items  that  are  used  in 
creating  and  describing  these  work  products.  (See  the  definition  of 
“configuration  management”  in  the  glossary.) 

Acquired  products  may  need  to  be  placed  under  configuration 
management  by  both  the  supplier  and  the  project.  Provisions  for 
conducting  configuration  management  should  be  established  in  supplier 
agreements.  Methods  to  ensure  that  the  data  is  complete  and 
consistent  should  be  established  and  maintained. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  establishing  and  maintaining  agreements  with 
suppliers. 
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Examples  of  work  products  that  may  be  placed  under  configuration  management 
include  the  following: 

•  Plans 

•  Process  descriptions 

•  Requirements 

•  Design  data 

•  Drawings 

•  Product  specifications 

•  Code 

•  Compilers 

•  Product  data  files 

•  Product  technical  publications 


Configuration  management  of  work  products  may  be  performed  at 
several  levels  of  granularity.  Configuration  items  can  be  decomposed 
into  configuration  components  and  configuration  units.  Only  the  term 
“configuration  item”  is  used  in  this  process  area.  Therefore,  in  these 
practices,  “configuration  item”  may  be  interpreted  as  “configuration 
component”  or  “configuration  unit”  as  appropriate.  (See  the  definition  of 
“configuration  item”  in  the  glossary.) 

Baselines  provide  a  stable  basis  for  continuing  evolution  of 
configuration  items. 


An  example  of  a  baseline  is  an  approved  description  of  a  product  that  includes 
internally  consistent  versions  of  requirements,  requirement  traceability  matrices,  design, 
discipline-specific  items,  and  end-user  documentation. 


Baselines  are  added  to  the  configuration  management  system  as  they 
are  developed.  Changes  to  baselines  and  the  release  of  work  products 
built  from  the  configuration  management  system  are  systematically 
controlled  and  monitored  via  the  configuration  control,  change 
management,  and  configuration  auditing  functions  of  configuration 
management. 

This  process  area  applies  not  only  to  configuration  management  on 
projects,  but  also  to  configuration  management  on  organizational  work 
products  such  as  standards,  procedures,  and  reuse  libraries. 

Configuration  management  is  focused  on  the  rigorous  control  of  the 
managerial  and  technical  aspects  of  work  products,  including  the 
delivered  system. 
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This  process  area  covers  the  practices  for  performing  the  configuration 
management  function  and  is  applicable  to  all  work  products  that  are 
placed  under  configuration  management. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  information  on 
developing  plans  and  work  breakdown  structures,  which  may  be  useful 
for  determining  configuration  items. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  performance  analyses  and  corrective  actions. 

Specific  Goal  and  Practice  Summary 

SG  1  Establish  Baselines 

SP  1 .1  Identify  Configuration  Items 
SP  1 .2  Establish  a  Configuration  Management  System 
SP  1 .3  Create  or  Release  Baselines 
SG  2  Track  and  Control  Changes 

SP  2.1  Track  Change  Requests 
SP  2.2  Control  Configuration  Items 
SG  3  Establish  Integrity 

SP  3.1  Establish  Configuration  Management  Records 
SP  3.2  Perform  Configuration  Audits 


Specific  Practices  by  Goal 


SG  1  Establish  Baselines 

Baselines  of  identified  work  products  are  established. 

Specific  practices  to  establish  baselines  are  covered  by  this  specific 
goal.  The  specific  practices  under  the  Track  and  Control  Changes 
specific  goal  serve  to  maintain  the  baselines.  The  specific  practices  of 
the  Establish  Integrity  specific  goal  document  and  audit  the  integrity  of 
the  baselines. 


SP  1.1  Identify  Configuration  Items 

Identify  the  configuration  items,  components,  and  related  work 
products  that  will  be  placed  under  configuration  management. 
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Configuration  identification  is  the  selection,  creation,  and  specification 
of  the  following: 

•  Products  that  are  delivered  to  the  customer 

•  Designated  internal  work  products 

•  Acquired  products 

•  Tools  and  other  capital  assets  of  the  project's  work  environment 

•  Other  items  that  are  used  in  creating  and  describing  these  work 
products 

Items  under  configuration  management  will  include  specifications  and 
interface  documents  that  define  the  requirements  for  the  product.  Other 
documents,  such  as  test  results,  may  also  be  included,  depending  on 
their  criticality  to  defining  the  product. 

A  “configuration  item”  is  an  entity  designated  for  configuration 
management,  which  may  consist  of  multiple  related  work  products  that 
form  a  baseline.  This  logical  grouping  provides  ease  of  identification 
and  controlled  access.  The  selection  of  work  products  for  configuration 
management  should  be  based  on  criteria  established  during  planning. 

Typical  Work  Products 
1.  Identified  configuration  items 

Subpractices 

1 .  Select  the  configuration  items  and  the  work  products  that  compose 
them  based  on  documented  criteria. 


Example  criteria  for  selecting  configuration  items  at  the  appropriate  work  product 
■  level  include  the  following: 

:  •  Work  products  that  may  be  used  by  two  or  more  groups 

i  •  Work  products  that  are  expected  to  change  over  time  either  because  of  errors  or 
change  of  requirements 

I  •  Work  products  that  are  dependent  on  each  other  in  that  a  change  in  one 
mandates  a  change  in  the  others 

:  •  Work  products  that  are  critical  for  the  project 
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SP  1.2 


Examples  of  work  products  that  may  be  part  of  a  configuration  item  include  the 
:  following: 

|  •  Process  descriptions 
:  •  Requirements 
i  •  Design 

;•  Test  plans  and  procedures 
i  •  Test  results 
:  •  Interface  descriptions 
:  •  Drawings 
|  •  Source  code 
•  Tools  _(e.g.,  compilers) 

2.  Assign  unique  identifiers  to  configuration  items. 

3.  Specify  the  important  characteristics  of  each  configuration  item. 

:  Example  characteristics  of  configuration  items  include  author,  document  or  file 
type,  and  programming  language  for  software  code  files. 


4.  Specify  when  each  configuration  item  is  placed  under  configuration 
management. 

:  Example  criteria  for  determining  when  to  place  work  products  under  configuration 
:  management  include  the  following: 

:  •  Stage  of  the  project  lifecycle 
i  •  When  the  work  product  is  ready  for  test 
j  •  Degree  of  control  desired  on  the  work  product 
j  •  Cost  and  schedule  limitations 
•  Customer  requirements 

5.  Identify  the  owner  responsible  for  each  configuration  item. 

Establish  a  Configuration  Management  System 

Establish  and  maintain  a  configuration  management  and 
change  management  system  for  controlling  work  products. 

A  configuration  management  system  includes  the  storage  media,  the 
procedures,  and  the  tools  for  accessing  the  configuration  system. 

A  change  management  system  includes  the  storage  media,  the 
procedures,  and  tools  for  recording  and  accessing  change  requests. 
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Typical  Work  Products 

1 .  Configuration  management  system  with  controlled  work  products 

2.  Configuration  management  system  access  control  procedures 

3.  Change  request  database 

Subpractices 

1.  Establish  a  mechanism  to  manage  multiple  control  levels  of 
configuration  management. 

The  level  of  control  is  typically  selected  based  on  project  objectives,  risk,  and/or 
resources.  Control  levels  may  vary  in  relation  to  the  project  lifecycle,  type  of 
system  under  development,  and  specific  project  requirements. 


Example  levels  of  control  include  the  following: 

•  Create  -  controlled  by  author 

•  Engineering  -  notification  to  relevant  stakeholders  when  changes  are  made 

•  Development  -  lower  level  CCB  control 

•  Formal  -  higher  level  CCB  control  with  customer  involvement 


Levels  of  control  can  range  from  informal  control  that  simply  tracks  changes  made 
when  the  configuration  items  are  being  developed  to  formal  configuration  control 
using  baselines  that  can  only  be  changed  as  part  of  a  formal  configuration 
management  process. 

2.  Store  and  retrieve  configuration  items  in  a  configuration 
management  system. 


Examples  of  configuration  management  systems  include  the  following: 

•  Dynamic  (or  author’s)  systems  contain  components  currently  being  created  or 
revised.  They  are  in  the  author’s  workspace  and  are  controlled  by  the  author. 
Configuration  items  in  a  dynamic  system  are  under  version  control. 

•  Master  (or  controlled)  systems  contain  current  baselines  and  changes  to  them. 
Configuration  items  in  a  master  system  are  under  full  configuration  management 
as  described  in  this  process  area. 

•  Static  systems  contain  archives  of  various  baselines  released  for  use.  Static 
systems  are  under  full  configuration  management  as  described  in  this  process 
area. 


3.  Share  and  transfer  configuration  items  between  control  levels 
within  the  configuration  management  system. 

4.  Store  and  recover  archived  versions  of  configuration  items. 

5.  Store,  update,  and  retrieve  configuration  management  records. 
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6.  Create  configuration  management  reports  from  the  configuration 
management  system. 

7.  Preserve  the  contents  of  the  configuration  management  system. 


:  Examples  of  preservation  functions  of  the  configuration  management  system 
:  include  the  following:  j 

:  •  Backups  and  restoration  of  configuration  management  files  : 

i  •  Archiving  of  configuration  management  files  j 

!  ! 

:  •  Recovery  from  configuration  management  errors 


8.  Revise  the  configuration  management  structure  as  necessary. 


SP  1.3  Create  or  Release  Baselines 

Create  or  release  baselines  for  internal  use  and  for  delivery  to 
the  customer. 


A  baseline  is  a  set  of  specifications  or  work  products  that  has  been 
formally  reviewed  and  agreed  on,  that  thereafter  serves  as  the  basis  for 
further  development  or  delivery,  and  that  can  be  changed  only  through 
change  control  procedures.  A  baseline  represents  the  assignment  of  an 
identifier  to  a  configuration  item  or  a  collection  of  configuration  items 
and  associated  entities.  As  a  product  evolves,  several  baselines  may  be 
used  to  control  its  development  and  testing. 


For  Systems  Engineering 

One  common  set  of  baselines  includes  the  system-level  requirements, 
system-element-level  design  requirements,  and  the  product  definition  at  the 
end  of  development/beginning  of  production.  These  are  typically  referred  to 
as  the  “functional  baseline,  ”  “allocated  baseline,  ”  and  “product  baseline.  ” 


For  Software  Engineering 

A  software  baseline  can  be  a  set  of  requirements,  design,  source  code  files 
and  the  associated  executable  code,  build  files,  and  user  documentation 
(associated  entities)  that  have  been  assigned  a  unique  identifier. 


Typical  Work  Products 

1.  Baselines 

2.  Description  of  baselines 
Subpractices 

1.  Obtain  authorization  from  the  configuration  control  board  (CCB) 
before  creating  or  releasing  baselines  of  configuration  items. 
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2.  Create  or  release  baselines  only  from  configuration  items  in  the 
configuration  management  system. 

3.  Document  the  set  of  configuration  items  that  are  contained  in  a 
baseline. 

4.  Make  the  current  set  of  baselines  readily  available. 


SG  2  Track  and  Control  Changes 

Changes  to  the  work  products  under  configuration  management  are 
tracked  and  controlled. 

The  specific  practices  under  this  specific  goal  serve  to  maintain  the 
baselines  after  they  are  established  by  the  specific  practices  under  the 
Establish  Baselines  specific  goal. 


SP  2.1  Track  Change  Requests 

Track  change  requests  for  the  configuration  items. 


Change  requests  address  not  only  new  or  changed  requirements,  but 
also  failures  and  defects  in  the  work  products. 

Change  requests  are  analyzed  to  determine  the  impact  that  the  change 
will  have  on  the  work  product,  related  work  products,  budget,  and 
schedule. 

Typical  Work  Products 

1.  Change  requests 

Subpractices 

1.  Initiate  and  record  change  requests  in  the  change  request 
database. 

2.  Analyze  the  impact  of  changes  and  fixes  proposed  in  the  change 
requests. 

Changes  are  evaluated  through  activities  that  ensure  that  they  are  consistent  with 
all  technical  and  project  requirements. 

Changes  are  evaluated  for  their  impact  beyond  immediate  project  or  contract 
requirements.  Changes  to  an  item  used  in  multiple  products  can  resolve  an 
immediate  issue  while  causing  a  problem  in  other  applications. 

3.  Review  change  requests  that  will  be  addressed  in  the  next  baseline 
with  the  relevant  stakeholders  and  get  their  agreement. 

Conduct  the  change  request  review  with  appropriate  participants.  Record  the 
disposition  of  each  change  request  and  the  rationale  for  the  decision,  including 
success  criteria,  a  brief  action  plan  if  appropriate,  and  needs  met  or  unmet  by  the 
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change.  Perform  the  actions  required  in  the  disposition,  and  report  the  results  to 
relevant  stakeholders. 

4.  Track  the  status  of  change  requests  to  closure. 

Change  requests  brought  into  the  system  need  to  be  handled  in  an  efficient  and 
timely  manner.  Once  a  change  request  has  been  processed,  it  is  critical  to  close 
the  request  with  the  appropriate  approved  action  as  soon  as  it  is  practical.  Actions 
left  open  result  in  larger  than  necessary  status  lists,  which  in  turn  result  in  added 
costs  and  confusion. 


SP  2.2  Control  Configuration  Items 

Control  changes  to  the  configuration  items. 


Control  is  maintained  over  the  configuration  of  the  work  product 
baseline.  This  control  includes  tracking  the  configuration  of  each  of  the 
configuration  items,  approving  a  new  configuration  if  necessary,  and 
updating  the  baseline. 

Typical  Work  Products 

1 .  Revision  history  of  configuration  items 

2.  Archives  of  the  baselines 

Subpractices 

1 .  Control  changes  to  configuration  items  throughout  the  life  of  the 
product. 

2.  Obtain  appropriate  authorization  before  changed  configuration 
items  are  entered  into  the  configuration  management  system. 


For  example,  authorization  may  come  from  the  CCB,  the  project  manager,  or  the 
customer. 


3.  Check  in  and  check  out  configuration  items  from  the  configuration 
management  system  for  incorporation  of  changes  in  a  manner  that 
maintains  the  correctness  and  integrity  of  the  configuration  items. 


Examples  of  check-in  and  check-out  steps  include  the  following: 

•  Confirming  that  the  revisions  are  authorized 

•  Updating  the  configuration  items 

•  Archiving  the  replaced  baseline  and  retrieving  the  new  baseline 


4.  Perform  reviews  to  ensure  that  changes  have  not  caused 

unintended  effects  on  the  baselines  (e.g.,  ensure  that  the  changes 
have  not  compromised  the  safety  and/or  security  of  the  system). 


122 


Configuration  Management  (CM) 


SG  3 


CMMI  for  Development 
Version  1.2 

5.  Record  changes  to  configuration  items  and  the  reasons  for  the 
changes  as  appropriate. 

If  a  proposed  change  to  the  work  product  is  accepted,  a  schedule  is  identified  for 
incorporating  the  change  into  the  work  product  and  other  affected  areas. 

Configuration  control  mechanisms  can  be  tailored  to  categories  of  changes.  For 
example,  the  approval  considerations  could  be  less  stringent  for  component 
changes  that  do  not  affect  other  components. 

Changed  configuration  items  are  released  after  review  and  approval  of 
configuration  changes.  Changes  are  not  official  until  they  are  released. 


Establish  Integrity 

Integrity  of  baselines  is  established  and  maintained. 

The  integrity  of  the  baselines,  established  by  processes  associated  with 
the  Establish  Baselines  specific  goal,  and  maintained  by  processes 
associated  with  the  Track  and  Control  Changes  specific  goal,  is 
provided  by  the  specific  practices  under  this  specific  goal. 


SP  3.1  Establish  Configuration  Management  Records 

Establish  and  maintain  records  describing  configuration  items. 


Typical  Work  Products 

1 .  Revision  history  of  configuration  items 

2.  Change  log 

3.  Copy  of  the  change  requests 

4.  Status  of  configuration  items 

5.  Differences  between  baselines 

Subpractices 

1 .  Record  configuration  management  actions  in  sufficient  detail  so  the 
content  and  status  of  each  configuration  item  is  known  and 
previous  versions  can  be  recovered. 

2.  Ensure  that  relevant  stakeholders  have  access  to  and  knowledge 
of  the  configuration  status  of  the  configuration  items. 

Examples  of  activities  for  communicating  configuration  status  include  the 
:  following: 

i  •  Providing  access  permissions  to  authorized  end  users 
•  Making  baseline  copies  readily  available  to  authorized  end  users 

3.  Specify  the  latest  version  of  the  baselines. 
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4.  Identify  the  version  of  configuration  items  that  constitute  a 
particular  baseline. 

5.  Describe  the  differences  between  successive  baselines. 

6.  Revise  the  status  and  history  (i.e.,  changes  and  other  actions)  of 
each  configuration  item  as  necessary. 


SP  3.2  Perform  Configuration  Audits 

Perform  configuration  audits  to  maintain  integrity  of  the 
configuration  baselines. 


Configuration  audits  confirm  that  the  resulting  baselines  and 
documentation  conform  to  a  specified  standard  or  requirement.  Audit 
results  should  be  recorded  as  appropriate.  (See  the  glossary  for  a 
definition  of  “configuration  audit.”) 


Examples  of  audit  types  include  the  following: 

•  Functional  Configuration  Audits  (FCA)  -  Audits  conducted  to  verify  that  the  as- 
tested  functional  characteristics  of  a  configuration  item  have  achieved  the 
requirements  specified  in  its  functional  baseline  documentation  and  that  the 
operational  and  support  documentation  is  complete  and  satisfactory. 

•  Physical  Configuration  Audit  (PCA)  -  Audits  conducted  to  verify  that  the  as-built 
configuration  item  conforms  to  the  technical  documentation  that  defines  it. 

•  Configuration  management  audits  -  Audits  conducted  to  confirm  that  configuration 
management  records  and  configuration  items  are  complete,  consistent,  and 
accurate. 


Typical  Work  Products 

1 .  Configuration  audit  results 

2.  Action  items 
Subpractices 

1 .  Assess  the  integrity  of  the  baselines. 

2.  Confirm  that  the  configuration  management  records  correctly 
identify  the  configuration  items. 

3.  Review  the  structure  and  integrity  of  the  items  in  the  configuration 
management  system. 

4.  Confirm  the  completeness  and  correctness  of  the  items  in  the 
configuration  management  system. 

Completeness  and  correctness  of  the  content  is  based  on  the  requirements  as 
stated  in  the  plan  and  the  disposition  of  approved  change  requests. 
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5.  Confirm  compliance  with  applicable  configuration  management 
standards  and  procedures. 

6.  Track  action  items  from  the  audit  to  closure. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  configuration  management 
process  to  develop  work  products  and  provide  services  to 
achieve  the  specific  goals  of  the  process  area. 


GG  2  institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  configuration  management  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  baselines,  tracking  and  controlling  changes  to  the  work 
products  (under  configuration  management),  and  establishing  and 
maintaining  integrity  of  the  baselines. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
configuration  management  process. 


Elaboration: 

This  plan  for  performing  the  configuration  management  process  can  be 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  configuration 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 

Elaboration: 

Examples  of  resources  provided  include  the  following  tools: 

:•  Configuration  management  tools 
|  •  Data  management  tools 
|  •  Archiving  and  reproduction  tools 

i 

•  Database  programs 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  configuration  management  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  configuration 
management  process  as  needed. 

Elaboration: 

:  Examples  of  training  topics  include  the  following: 

;  •  Roles,  responsibilities,  and  authority  of  the  configuration  management  staff 

:  •  Configuration  management  standards,  procedures,  and  methods 

•  Configuration  library  system 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  configuration 
management  process  under  appropriate  levels  of  control. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.6 
and  the  Configuration  Management  process  area. 
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Examples  of  work  products  placed  under  control  include  the  following: 

•  Access  lists 

•  Change  status  reports 

•  Change  request  database 

•  CCB  meeting  minutes 

•  Archived  baselines 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
configuration  management  process  as  planned. 

Elaboration: 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

;  •  Establishing  baselines 

I  •  Reviewing  configuration  management  system  reports  and  resolving  issues 
:  •  Assessing  the  impact  of  changes  for  the  configuration  items 
:  •  Performing  configuration  audits 
;  •  Reviewing  the  results  of  configuration  management  audits 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  configuration  management  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  changes  to  configuration  items 

•  Number  of  configuration  audits  conducted 

•  Schedule  of  CCB  or  audit  activities 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  configuration 
management  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 
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Elaboration: 

:  Examples  of  activities  reviewed  include  the  following: 

I  •  Establishing  baselines 

;•  Tracking  and  controlling  changes 

:  •  Establishing  and  maintaining  integrity  of  baselines 

;  Examples  of  work  products  reviewed  include  the  following: 
;  •  Archives  of  the  baselines 
•  Change  request  database 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  configuration 
management  process  with  higher  level  management  and 
resolve  issues. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 

Continuous/Maturity  Levels  3  -  5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
configuration  management  process. 
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Continuous/Maturity  Levels  3  -  5  Only 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  configuration  management  process  to  support 
the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  T rends  in  the  status  of  configuration  items 

•  Configuration  audit  results 

•  Change  request  aging  reports 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
configuration  management  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  configuration  management  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  configuration 
management  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 
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Continuous  Only 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  configuration  management  process. 
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DECISION  ANALYSIS  AND  RESOLUTION 

A  Support  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Decision  Analysis  and  Resolution  (DAR)  is  to  analyze 
possible  decisions  using  a  formal  evaluation  process  that  evaluates 
identified  alternatives  against  established  criteria. 


Introductory  Notes 


The  Decision  Analysis  and  Resolution  process  area  involves 
establishing  guidelines  to  determine  which  issues  should  be  subjected 
to  a  formal  evaluation  process  and  then  applying  formal  evaluation 
processes  to  these  issues. 

A  formal  evaluation  process  is  a  structured  approach  to  evaluating 
alternative  solutions  against  established  criteria  to  determine  a 
recommended  solution  to  address  an  issue.  A  formal  evaluation 
process  involves  the  following  actions: 

•  Establishing  the  criteria  for  evaluating  alternatives 

•  Identifying  alternative  solutions 

•  Selecting  methods  for  evaluating  alternatives 

•  Evaluating  the  alternative  solutions  using  the  established  criteria 
and  methods 

•  Selecting  recommended  solutions  from  the  alternatives  based  on 
the  evaluation  criteria 

Rather  than  using  the  phrase  “alternative  solutions  to  address  issues” 
each  time  it  is  needed,  we  will  use  one  of  two  shorter  phrases: 
“alternative  solutions”  or  “alternatives.” 

A  formal  evaluation  process  reduces  the  subjective  nature  of  the 
decision  and  has  a  higher  probability  of  selecting  a  solution  that  meets 
the  multiple  demands  of  relevant  stakeholders. 

While  the  primary  application  of  this  process  area  is  to  technical 
concerns,  formal  evaluation  processes  can  also  be  applied  to  many 
nontechnical  issues,  particularly  when  a  project  is  being  planned. 
Issues  that  have  multiple  alternative  solutions  and  evaluation  criteria 
lend  themselves  to  a  formal  evaluation  process. 
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:  Trade  studies  of  equipment  or  software  are  typical  examples  of  formal  evaluation 
processes. 


During  planning,  specific  issues  requiring  a  formal  evaluation  process 
are  identified.  Typical  issues  include  selection  among  architectural  or 
design  alternatives,  use  of  reusable  or  commercial  off-the-shelf  (COTS) 
components,  supplier  selection,  engineering  support  environments  or 
associated  tools,  test  environments,  delivery  alternatives,  and  logistics 
and  production.  A  formal  evaluation  process  can  also  be  used  to 
address  a  make-or-buy  decision,  the  development  of  manufacturing 
processes,  the  selection  of  distribution  locations,  and  other  decisions. 

Guidelines  are  created  for  deciding  when  to  use  formal  evaluation 
processes  to  address  unplanned  issues.  Guidelines  often  suggest  using 
formal  evaluation  processes  when  issues  are  associated  with  medium 
to  high  risks  or  when  issues  affect  the  ability  to  achieve  project 
objectives. 

Formal  evaluation  processes  can  vary  in  formality,  type  of  criteria,  and 
methods  employed.  Less  formal  decisions  can  be  analyzed  in  a  few 
hours,  use  only  a  few  criteria  (e.g.,  effectiveness  and  cost  to 
implement),  and  result  in  a  one-  or  two-page  report.  More  formal 
decisions  may  require  separate  plans,  months  of  effort,  meetings  to 
develop  and  approve  criteria,  simulations,  prototypes,  piloting,  and 
extensive  documentation. 

Both  numeric  and  non-numeric  criteria  can  be  used  in  a  formal 
evaluation  process.  Numeric  criteria  use  weights  to  reflect  the  relative 
importance  of  the  criteria.  Non-numeric  criteria  use  a  more  subjective 
ranking  scale  (e.g.,  high,  medium,  or  low).  More  formal  decisions  may 
require  a  full  trade  study. 

A  formal  evaluation  process  identifies  and  evaluates  alternative 
solutions.  The  eventual  selection  of  a  solution  may  involve  iterative 
activities  of  identification  and  evaluation.  Portions  of  identified 
alternatives  may  be  combined,  emerging  technologies  may  change 
alternatives,  and  the  business  situation  of  vendors  may  change  during 
the  evaluation  period. 

A  recommended  alternative  is  accompanied  by  documentation  of  the 
selected  methods,  criteria,  alternatives,  and  rationale  for  the 
recommendation.  The  documentation  is  distributed  to  relevant 
stakeholders;  it  provides  a  record  of  the  formal  evaluation  process  and 
rationale  that  are  useful  to  other  projects  that  encounter  a  similar  issue. 

While  some  of  the  decisions  made  throughout  the  life  of  the  project 
involve  the  use  of  a  formal  evaluation  process,  others  do  not.  As 
mentioned  earlier,  guidelines  should  be  established  to  determine  which 
issues  should  be  subjected  to  a  formal  evaluation  process. 
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Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
general  planning  for  projects. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process.  The 
project’s  defined  process  includes  a  formal  evaluation  process  for  each 
selected  issue  and  incorporates  the  use  of  guidelines  for  applying  a 
formal  evaluation  process  to  unforeseen  issues. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  mitigating  risks.  A  formal  evaluation  process  is  often 
used  to  address  issues  with  identified  medium  or  high  risks.  Selected 
solutions  typically  affect  risk  mitigation  plans. 

Specific  Goal  and  Practice  Summary 

SG  1  Evaluate  Alternatives 

SP  1 . 1  Establish  Guidelines  for  Decision  Analysis 

SP  1.2  Establish  Evaluation  Criteria 

SP  1 .3  Identify  Alternative  Solutions 

SP  1 .4  Select  Evaluation  Methods 

SP  1 .5  Evaluate  Alternatives 

SP  1 .6  Select  Solutions 

Specific  Practices  by  Goal 


SG  1  Evaluate  Alternatives 

Decisions  are  based  on  an  evaluation  of  alternatives  using  established 
criteria. 

Issues  requiring  a  formal  evaluation  process  may  be  identified  at  any 
time.  The  objective  should  be  to  identify  issues  as  early  as  possible  to 
maximize  the  time  available  to  resolve  them. 


SP  1.1  Establish  Guidelines  for  Decision  Analysis 

Establish  and  maintain  guidelines  to  determine  which  issues 
are  subject  to  a  formal  evaluation  process. 


Not  every  decision  is  significant  enough  to  require  a  formal  evaluation 
process.  The  choice  between  the  trivial  and  the  truly  important  will  be 
unclear  without  explicit  guidance.  Whether  a  decision  is  significant  or 
not  is  dependent  on  the  project  and  circumstances,  and  is  determined 
by  the  established  guidelines. 
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Typical  guidelines  for  determining  when  to  require  a  formal  evaluation 

process  include  the  following: 

•  When  a  decision  is  directly  related  to  topics  assessed  as  being  of 
medium  or  high  risk 

•  When  a  decision  is  related  to  changing  work  products  under 
configuration  management 

•  When  a  decision  would  cause  schedule  delays  over  a  certain 
percentage  or  specific  amount  of  time 

•  When  a  decision  affects  the  ability  to  achieve  project  objectives 

•  When  the  costs  of  the  formal  evaluation  process  are  reasonable 
when  compared  to  the  decision’s  impact 

•  When  a  legal  obligation  exists  during  a  solicitation 

Refer  to  the  Risk  Management  process  area  for  more  information  about 

determining  which  issues  are  medium  or  high  risk. 


Examples  of  when  to  use  a  formal  evaluation  process  include  the  following: 

•  On  decisions  involving  the  procurement  of  material  when  20  percent  of  the  material 
parts  constitute  80  percent  of  the  total  material  costs 

•  On  design-implementation  decisions  when  technical  performance  failure  may 
cause  a  catastrophic  failure  (e.g.,  safety  of  flight  item) 

•  On  decisions  with  the  potential  to  significantly  reduce  design  risk,  engineering 
changes,  cycle  time,  response  time,  and  production  costs  (e.g.,  to  use  lithography 
models  to  assess  form  and  fit  capability  before  releasing  engineering  drawings  and 
production  builds) 


Typical  Work  Products 

1 .  Guidelines  for  when  to  apply  a  formal  evaluation  process 
Subpractices 

1.  Establish  guidelines. 

2.  Incorporate  the  use  of  the  guidelines  into  the  defined  process 
where  appropriate. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

SP  1.2  Establish  Evaluation  Criteria 

Establish  and  maintain  the  criteria  for  evaluating  alternatives, 
and  the  relative  ranking  of  these  criteria. 
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The  evaluation  criteria  provide  the  basis  for  evaluating  alternative 
solutions.  The  criteria  are  ranked  so  that  the  highest  ranked  criteria 
exert  the  most  influence  on  the  evaluation. 

This  process  area  is  referenced  by  many  other  process  areas  in  the 
model,  and  there  are  many  contexts  in  which  a  formal  evaluation 
process  can  be  used.  Therefore,  in  some  situations  you  may  find  that 
criteria  have  already  been  defined  as  part  of  another  process.  This 
specific  practice  does  not  suggest  that  a  second  development  of  criteria 
be  conducted. 

Document  the  evaluation  criteria  to  minimize  the  possibility  that 
decisions  will  be  second-guessed,  or  that  the  reason  for  making  the 
decision  will  be  forgotten.  Decisions  based  on  criteria  that  are  explicitly 
defined  and  established  remove  barriers  to  stakeholder  buy-in. 

Typical  Work  Products 

1.  Documented  evaluation  criteria 

2.  Rankings  of  criteria  importance 
Subpractices 

1 .  Define  the  criteria  for  evaluating  alternative  solutions. 

Criteria  should  be  traceable  to  requirements,  scenarios,  business  case 
assumptions,  business  objectives,  or  other  documented  sources.  Types  of  criteria 
to  consider  include  the  following: 

•  Technology  limitations 

•  Environmental  impact 

•  Risks 

•  Total  ownership  and  lifecycle  costs 

2.  Define  the  range  and  scale  for  ranking  the  evaluation  criteria. 

Scales  of  relative  importance  for  evaluation  criteria  can  be  established  with  non¬ 
numeric  values  or  with  formulas  that  relate  the  evaluation  parameter  to  a  numeric 
weight. 

3.  Rank  the  criteria. 

The  criteria  are  ranked  according  to  the  defined  range  and  scale  to  reflect  the 
needs,  objectives,  and  priorities  of  the  relevant  stakeholders. 

4.  Assess  the  criteria  and  their  relative  importance. 

5.  Evolve  the  evaluation  criteria  to  improve  their  validity. 

6.  Document  the  rationale  for  the  selection  and  rejection  of  evaluation 
criteria. 
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Documentation  of  selection  criteria  and  rationale  may  be  needed  to  justify 
solutions  or  for  future  reference  and  use. 

SP  1.3  Identify  Alternative  Solutions 

Identify  alternative  solutions  to  address  issues. 


A  wider  range  of  alternatives  can  surface  by  soliciting  as  many 
stakeholders  as  practical  for  input.  Input  from  stakeholders  with  diverse 
skills  and  backgrounds  can  help  teams  identify  and  address 
assumptions,  constraints,  and  biases.  Brainstorming  sessions  may 
stimulate  innovative  alternatives  through  rapid  interaction  and  feedback. 
Sufficient  candidate  solutions  may  not  be  furnished  for  analysis.  As  the 
analysis  proceeds,  other  alternatives  should  be  added  to  the  list  of 
potential  candidate  solutions.  The  generation  and  consideration  of 
multiple  alternatives  early  in  a  decision  analysis  and  resolution  process 
increases  the  likelihood  that  an  acceptable  decision  will  be  made,  and 
that  consequences  of  the  decision  will  be  understood. 

Typical  Work  Products 

1.  Identified  alternatives 

Subpractices 

1.  Perform  a  literature  search. 

A  literature  search  can  uncover  what  others  have  done  both  inside  and  outside 
the  organization.  It  may  provide  a  deeper  understanding  of  the  problem, 
alternatives  to  consider,  barriers  to  implementation,  existing  trade  studies,  and 
lessons  learned  from  similar  decisions. 

2.  Identify  alternatives  for  consideration  in  addition  to  those  that  may 
be  provided  with  the  issue. 

Evaluation  criteria  are  an  effective  starting  point  for  identifying  alternatives.  The 
evaluation  criteria  identify  the  priorities  of  the  relevant  stakeholders  and  the 
importance  of  technical,  logistical,  or  other  challenges. 

Combining  key  attributes  of  existing  alternatives  can  generate  additional  and 
sometimes  stronger  alternatives. 

Solicit  alternatives  from  relevant  stakeholders.  Brainstorming  sessions,  interviews, 
and  working  groups  can  be  used  effectively  to  uncover  alternatives. 

3.  Document  the  proposed  alternatives. 


SP  1.4  Select  Evaluation  Methods 

Select  the  evaluation  methods. 


Methods  for  evaluating  alternative  solutions  against  established  criteria 
can  range  from  simulations  to  the  use  of  probabilistic  models  and 
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decision  theory.  These  methods  need  to  be  carefully  selected.  The  level 
of  detail  of  a  method  should  be  commensurate  with  cost,  schedule, 
performance,  and  risk  impacts. 

While  many  problems  may  need  only  one  evaluation  method,  some 
problems  may  require  multiple  methods.  For  instance,  simulations  may 
augment  a  trade  study  to  determine  which  design  alternative  best 
meets  a  given  criterion. 

Typical  Work  Products 

1.  Selected  evaluation  methods 

Subpractices 

1 .  Select  the  methods  based  on  the  purpose  for  analyzing  a  decision 
and  on  the  availability  of  the  information  used  to  support  the 
method. 


For  example,  the  methods  used  for  evaluating  a  solution  when  requirements  are 
■  weakly  defined  may  be  different  from  the  methods  used  when  the  requirements 
are  well  defined. 

Typical  evaluation  methods  include  the  following: 

•  Modeling  and  simulation 

•  Engineering  studies 

•  Manufacturing  studies 

•  Cost  studies 

•  Business  opportunity  studies 

•  Surveys 

•  Extrapolations  based  on  field  experience  and  prototypes 

•  User  review  and  comment 

•  Testing 

•  Judgment  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi  Method) 

2.  Select  evaluation  methods  based  on  their  ability  to  focus  on  the 
issues  at  hand  without  being  overly  influenced  by  side  issues. 

Results  of  simulations  can  be  skewed  by  random  activities  in  the  solution  that  are 
not  directly  related  to  the  issues  at  hand. 

3.  Determine  the  measures  needed  to  support  the  evaluation  method. 
Consider  the  impact  on  cost,  schedule,  performance,  and  risks. 
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SP1.5  Evaluate  Alternatives 

Evaluate  alternative  solutions  using  the  established  criteria  and 
methods. 


Evaluating  alternative  solutions  involves  analysis,  discussion,  and 
review.  Iterative  cycles  of  analysis  are  sometimes  necessary. 

Supporting  analyses,  experimentation,  prototyping,  piloting,  or 
simulations  may  be  needed  to  substantiate  scoring  and  conclusions. 

Often,  the  relative  importance  of  criteria  is  imprecise  and  the  total  effect 
on  a  solution  is  not  apparent  until  after  the  analysis  is  performed.  In 
cases  where  the  resulting  scores  differ  by  relatively  small  amounts,  the 
best  selection  among  alternative  solutions  may  not  be  clear  cut. 
Challenges  to  criteria  and  assumptions  should  be  encouraged. 

Typical  Work  Products 

1.  Evaluation  results 

Subpractices 

1.  Evaluate  the  proposed  alternative  solutions  using  the  established 
evaluation  criteria  and  selected  methods. 

2.  Evaluate  the  assumptions  related  to  the  evaluation  criteria  and  the 
evidence  that  supports  the  assumptions. 

3.  Evaluate  whether  uncertainty  in  the  values  for  alternative  solutions 
affects  the  evaluation  and  address  as  appropriate. 

For  instance,  if  the  score  can  vary  between  two  values,  is  the  difference 
significant  enough  to  make  a  difference  in  the  final  solution  set?  Does  the 
variation  in  score  represent  a  high  risk?  To  address  these  concerns,  simulations 
may  be  run,  further  studies  may  be  performed,  or  evaluation  criteria  may  be 
modified,  among  other  things. 

4.  Perform  simulations,  modeling,  prototypes,  and  pilots  as  necessary 
to  exercise  the  evaluation  criteria,  methods,  and  alternative 
solutions. 

Untested  criteria,  their  relative  importance,  and  supporting  data  or  functions  may 
cause  the  validity  of  solutions  to  be  questioned.  Criteria  and  their  relative  priorities 
and  scales  can  be  tested  with  trial  runs  against  a  set  of  alternatives.  These  trial 
runs  of  a  select  set  of  criteria  allow  for  the  evaluation  of  the  cumulative  impact  of 
the  criteria  on  a  solution.  If  the  trials  reveal  problems,  different  criteria  or 
alternatives  might  be  considered  to  avoid  biases. 

5.  Consider  new  alternative  solutions,  criteria,  or  methods  if  the 
proposed  alternatives  do  not  test  well;  repeat  the  evaluations  until 
alternatives  do  test  well. 

6.  Document  the  results  of  the  evaluation. 
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Document  the  rationale  for  the  addition  of  new  alternatives  or  methods  and 
changes  to  criteria,  as  well  as  the  results  of  interim  evaluations. 


SP  1.6  Select  Solutions 

Select  solutions  from  the  alternatives  based  on  the  evaluation 
criteria. 


Selecting  solutions  involves  weighing  the  results  from  the  evaluation  of 
alternatives.  Risks  associated  with  implementation  of  the  solutions  must 
be  assessed. 

Typical  Work  Products 

1 .  Recommended  solutions  to  address  significant  issues 
Subpractices 

1.  Assess  the  risks  associated  with  implementing  the  recommended 
solution. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  managing  risks. 

Decisions  must  often  be  made  with  incomplete  information.  There  can  be 
substantial  risk  associated  with  the  decision  because  of  having  incomplete 
information. 

When  decisions  must  be  made  according  to  a  specific  schedule,  time  and 
resources  may  not  be  available  for  gathering  complete  information.  Consequently, 
risky  decisions  made  with  incomplete  information  may  require  re-analysis  later. 
Identified  risks  should  be  monitored. 

2.  Document  the  results  and  rationale  for  the  recommended  solution. 

It  is  important  to  record  both  why  a  solution  is  selected  and  why  another  solution 
was  rejected. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 
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Continuous  Only 

GP  1.1 

Perform  Specific  Practices 

Perform  the  specific  practices  of  the  decision  analysis  and 
resolution  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  decision  analysis  and  resolution  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  selectively 
analyzing  possible  decisions  using  a  formal  evaluation  process  that 
evaluates  identified  alternatives  against  established  criteria.  The  policy 
should  also  provide  guidance  on  which  decisions  require  a  formal 
evaluation  process. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  decision 
analysis  and  resolution  process. 


Elaboration: 

This  plan  for  performing  the  decision  analysis  and  resolution  process 
can  be  included  in  (or  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  decision 
analysis  and  resolution  process,  developing  the  work  products, 
and  providing  the  services  of  the  process. 

Elaboration: 

Examples  of  resources  provided  include  the  following  tools: 

I  •  Simulators  and  modeling  tools 

|  •  Prototyping  tools 

i 

•  Tools  for  conducting  surveys 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  decision  analysis  and  resolution  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  decision  analysis 
and  resolution  process  as  needed. 

Elaboration: 

:  Examples  of  training  topics  include  the  following: 

;  •  Formal  decision  analysis 

•  Methods  for  evaluating  alternative  solutions  against  criteria 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  decision  analysis  and 
resolution  process  under  appropriate  levels  of  control. 

Elaboration: 

;  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Guidelines  for  when  to  apply  a  formal  evaluation  process 
•  Evaluation  reports  containing  recommended  solutions 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  decision 
analysis  and  resolution  process  as  planned. 
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Elaboration: 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Establishing  guidelines  for  which  issues  are  subject  to  a  formal  evaluation  process 
j  •  Establishing  evaluation  criteria 

j  •  Identifying  and  evaluating  alternatives 

j  •  Selecting  evaluation  methods 

•  Selecting  solutions 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  decision  analysis  and  resolution 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Cost-to-benefit  ratio  of  using  formal  evaluation  processes 

•  Schedule  for  the  execution  of  a  trade  study 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  decision  analysis  and 
resolution  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

•  Evaluating  alternatives  using  established  criteria  and  methods 

'  Examples  of  work  products  reviewed  include  the  following: 

:  •  Guidelines  for  when  to  apply  a  formal  evaluation  process 
:  •  Evaluation  reports  containing  recommended  solutions 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  decision 
analysis  and  resolution  process  with  higher  level  management 
and  resolve  issues. 
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Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  decision 
analysis  and  resolution  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  decision  analysis  and  resolution  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Number  of  alternatives  considered 

•  Evaluation  results 

•  Recommended  solutions  to  address  significant  issues 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  decision 
analysis  and  resolution  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  decision  analysis  and  resolution 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 
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Continuous  Only 

GG  5  Institutionalize  an  Optimizing  Process 


The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  decision  analysis  and 
resolution  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  decision  analysis  and  resolution  process. 
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INTEGRATED  PROJECT  MANAGEMENT  +IPPD 

A  Project  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Integrated  Project  Management  (IPM)  is  to  establish 
and  manage  the  project  and  the  involvement  of  the  relevant 
stakeholders  according  to  an  integrated  and  defined  process  that  is 
tailored  from  the  organization’s  set  of  standard  processes. 


IPPD  Addition 

For  IPPD,  Integrated  Project  Management  +IPPD  also  covers  the 
establishment  of  a  shared  vision  for  the  project  and  the  establishment  of 
integrated  teams  that  will  carry  out  objectives  of  the  project. 


Introductory  Notes 


Integrated  Project  Management  involves  the  following: 

•  Establishing  the  project’s  defined  process  at  project  startup  by 
tailoring  the  organization’s  set  of  standard  processes 

•  Managing  the  project  using  the  project’s  defined  process 

•  Establishing  the  work  environment  for  the  project  based  on  the 
organization's  work  environment  standards 

•  Using  and  contributing  to  the  organizational  process  assets 

•  Enabling  relevant  stakeholders’  concerns  to  be  identified, 
considered,  and,  when  appropriate,  addressed  during  the 
development  of  the  product 

•  Ensuring  that  the  relevant  stakeholders  perform  their  tasks  in  a 
coordinated  and  timely  manner  (1)  to  address  product  and  product 
component  requirements,  plans,  objectives,  problems,  and  risks;  (2) 
to  fulfill  their  commitments;  and  (3)  to  identify,  track,  and  resolve 
coordination  issues 


IPPD  Addition 

Integrated  Project  Management  +IPPD  also  involves  the  following: 

•  Establishing  a  shared  vision  for  the  project 

•  Establishing  integrated  teams  that  are  tasked  to  accomplish  project 
objectives 
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The  integrated  and  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  is  called  the  project’s  defined 
process. 

Managing  the  project’s  effort,  cost,  schedule,  staffing,  risks,  and  other 
factors  is  tied  to  the  tasks  of  the  project’s  defined  process.  The 
implementation  and  management  of  the  project’s  defined  process  are 
typically  described  in  the  project  plan.  Certain  activities  may  be  covered 
in  other  plans  that  affect  the  project,  such  as  the  quality  assurance  plan, 
risk  management  strategy,  and  the  configuration  management  plan. 

Since  the  defined  process  for  each  project  is  tailored  from  the 
organization’s  set  of  standard  processes,  variability  among  projects  is 
typically  reduced  and  projects  can  more  easily  share  process  assets, 
data,  and  lessons  learned. 

This  process  area  also  addresses  the  coordination  of  all  activities 
associated  with  the  project  such  as  the  following: 

•  Development  activities  (e.g.,  requirements  development,  design, 
and  verification) 

•  Service  activities  (e.g.,  delivery,  help  desk,  operations,  and 
customer  contact) 

•  Acquisition  activities  (e.g.,  solicitation,  contract  monitoring,  and 
transition  to  operation) 

•  Support  activities  (e.g.,  configuration  management,  documentation, 
marketing,  and  training) 

The  working  interfaces  and  interactions  among  relevant  stakeholders 
internal  and  external  to  the  project  are  planned  and  managed  to  ensure 
the  quality  and  integrity  of  the  entire  product.  Relevant  stakeholders 
participate,  as  appropriate,  in  defining  the  project’s  defined  process  and 
the  project  plan.  Reviews  and  exchanges  are  regularly  conducted  with 
the  relevant  stakeholders  to  ensure  that  coordination  issues  receive 
appropriate  attention  and  everyone  involved  with  the  project  is 
appropriately  aware  of  the  status,  plans,  and  activities.  (See  the 
definition  of  “relevant  stakeholder”  in  the  glossary.)  In  defining  the 
project’s  defined  process,  formal  interfaces  are  created  as  necessary  to 
ensure  that  appropriate  coordination  and  collaboration  occurs. 

This  process  area  applies  in  any  organizational  structure,  including 
projects  that  are  structured  as  line  organizations,  matrix  organizations, 
or  integrated  teams.  The  terminology  should  be  appropriately 
interpreted  for  the  organizational  structure  in  place. 
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Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  the  project,  which  includes  identifying  relevant  stakeholders 
and  their  appropriate  involvement  in  the  project. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project. 

Refer  to  the  Verification  process  area  for  more  information  about  peer 
reviews. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and  work  environment 
standards. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  a  process  for  measuring  and  analyzing 
processes. 


IPPD  Addition 

Refer  to  the  Organizational  Process  Definition  +IPPD  process  area  for 
more  information  about  creating  the  organizational  rules  and  guidelines 
for  IPPD. 


Specific  Goal  and  Practice  Summary 

SG  1  Use  the  Project's  Defined  Process 

SP  1 .1  Establish  the  Project's  Defined  Process 

SP  1 .2  Use  Organizational  Process  Assets  for  Planning  Project  Activities 
SP  1 .3  Establish  the  Project's  Work  Environment 

SP1.4  Integrate  Plans 

SP  1 .5  Manage  the  Project  Using  the  Integrated  Plans 
SP  1 .6  Contribute  to  the  Organizational  Process  Assets 
SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 
SP  2.1  Manage  Stakeholder  Involvement 

SP  2.2  Manage  Dependencies 

SP  2.3  Resolve  Coordination  Issues 


IPPD  Addition 

SG  3  Apply  IPPD  Principles 

SP  3.1 

Establish  the  Project's  Shared  Vision 

SP  3.2 

Establish  the  Integrated  Team  Structure 

SP  3.3 

Allocate  Requirements  to  Integrated  Teams 

SP  3.4 

Establish  Integrated  Teams 

SP  3.5 

Ensure  Collaboration  among  Interfacing  Teams 

Integrated  Project  Management  +IPPD  (IPM+IPPD) 
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Specific  Practices  by  Goal 


SG  1  Use  the  Project’s  Defined  Process 

The  project  is  conducted  using  a  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes. 

The  project’s  defined  process  must  include  those  processes  from  the 
organization’s  set  of  standard  processes  that  address  all  processes 
necessary  to  acquire  or  develop  and  maintain  the  product.  The  product- 
related  lifecycle  processes,  such  as  the  manufacturing  and  support 
processes,  are  developed  concurrently  with  the  product. 


SP  1.1  Establish  the  Project’s  Defined  Process 

Establish  and  maintain  the  project's  defined  process  from 
project  startup  through  the  life  of  the  project. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives  and 
deploying  the  organization’s  set  of  standard  processes  on  projects. 

The  project’s  defined  process  consists  of  defined  processes  that  form 
an  integrated,  coherent  lifecycle  for  the  project. 


IPPD  Addition 

The  project’s  defined  process  supports  IPPD  with  processes  that 

•  Make  the  integrated  project  management  environment  more  amenable 
to  collocated  or  distributed  teams 

•  Select  the  project's  integrated  team  structure 

•  Allocate  limited  personnel  resources 

•  Implement  cross-integrated  team  communication 


The  project's  defined  process  should  satisfy  the  project's  contractual 
and  operational  needs,  opportunities,  and  constraints.  It  is  designed  to 
provide  a  best  fit  for  the  project’s  needs.  A  project's  defined  process  is 
based  on  the  following  factors: 

•  Customer  requirements 

•  Product  and  product  component  requirements 

•  Commitments 

•  Organizational  process  needs  and  objectives 
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•  Organization’s  set  of  standard  processes  and  tailoring  guidelines 

•  Operational  environment 

•  Business  environment 

Establishing  the  project’s  defined  process  at  project  startup  helps  to 
ensure  that  project  staff  and  stakeholders  implement  a  set  of  activities 
needed  to  efficiently  establish  an  initial  set  of  requirements  and  plans 
for  the  project.  As  the  project  progresses,  the  description  of  the  project’s 
defined  process  is  elaborated  and  revised  to  better  meet  the  project’s 
requirements  and  the  organization’s  process  needs  and  objectives. 

Also,  as  the  organization’s  set  of  standard  processes  change,  the 
project’s  defined  process  may  need  to  be  revised. 

Typical  Work  Products 

1 .  The  project’s  defined  process 

Subpractices 

1 .  Select  a  lifecycle  model  from  those  available  from  the 
organizational  process  assets. 


Examples  of  project  characteristics  that  could  affect  the  selection  of  lifecycle 
models  include  the  following: 

•  Size  of  the  project 

•  Experience  and  familiarity  of  staff  in  implementing  the  process 

•  Constraints  such  as  cycle  time  and  acceptable  defect  levels 


2.  Select  the  standard  processes  from  the  organization's  set  of 
standard  processes  that  best  fit  the  needs  of  the  project. 

3.  Tailor  the  organization’s  set  of  standard  processes  and  other 
organizational  process  assets  according  to  the  tailoring  guidelines 
to  produce  the  project’s  defined  process. 

Sometimes  the  available  lifecycle  models  and  standard  processes  are  inadequate 
to  meet  a  specific  project’s  needs.  Sometimes  the  project  will  be  unable  to 
produce  required  work  products  or  measures,  in  such  circumstances,  the  project 
will  need  to  seek  approval  to  deviate  from  what  is  required  by  the  organization. 
Waivers  are  provided  for  this  purpose. 

4.  Use  other  artifacts  from  the  organization's  process  asset  library  as 
appropriate. 
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Other  artifacts  may  include  the  following: 

•  Lessons-learned  documents 

•  Templates 

•  Example  documents 

•  Estimating  models 

5.  Document  the  project's  defined  process. 

The  project's  defined  process  covers  all  of  the  activities  for  the  project  and  its 
interfaces  to  relevant  stakeholders. 

:  Examples  of  project  activities  include  the  following: 

|  •  Project  planning 
|  •  Project  monitoring 
:  •  Requirements  development 
i  •  Requirements  management 
|  •  Supplier  management 
|  •  Configuration  management 
:  •  Quality  assurance 
i  •  Risk  management 
|  •  Decision  analysis  and  resolution 
:  •  Product  development  and  support 

•  Solicitation 

6.  Conduct  peer  reviews  of  the  project's  defined  process. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews. 

7.  Revise  the  project's  defined  process  as  necessary. 

SP  1.2  Use  Organizational  Process  Assets  for  Planning  Project  Activities 

Use  the  organizational  process  assets  and  measurement 
repository  for  estimating  and  planning  the  project’s  activities. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and  the  organization’s 
measurement  repository. 
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Subpractices 

1 .  Use  the  tasks  and  work  products  of  the  project's  defined  process 
as  a  basis  for  estimating  and  planning  the  project's  activities. 

An  understanding  of  the  relationships  among  the  various  tasks  and  work  products 
of  the  project's  defined  process,  and  of  the  roles  to  be  performed  by  the  relevant 
stakeholders,  is  a  basis  for  developing  a  realistic  plan. 

2.  Use  the  organization’s  measurement  repository  in  estimating  the 
project’s  planning  parameters. 

This  estimate  typically  includes  the  following: 

•  Using  appropriate  historical  data  from  this  project  or  similar  projects 

•  Accounting  for  and  recording  similarities  and  differences  between  the  current 
project  and  those  projects  whose  historical  data  will  be  used 

•  Independently  validating  the  historical  data 

•  Recording  the  reasoning,  assumptions,  and  rationale  used  to  select  the  historical 
data 


Examples  of  parameters  that  are  considered  for  similarities  and  differences 
include  the  following: 

•  Work  product  and  task  attributes 

•  Application  domain 

•  Design  approach 

•  Operational  environment 

•  Experience  of  the  people 


:  Examples  of  data  contained  in  the  organization’s  measurement  repository  include 
:  the  following: 

|  •  Size  of  work  products  or  other  work  product  attributes 
i  •  Effort 
i  •  Cost 
j  •  Schedule 
|  •  Staffing 
:  •  Defects 
i  •  Response  time 
|  •  Service  capacity 
•  Supplier  performance 
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SP  1.3  Establish  the  Project's  Work  Environment 

Establish  and  maintain  the  project's  work  environment  based 
on  the  organization's  work  environment  standards. 


An  appropriate  work  environment  for  a  project  comprises  an 
infrastructure  of  facilities,  tools,  and  equipment  that  people  need  to 
perform  their  jobs  effectively  in  support  of  business  and  project 
objectives.  The  work  environment  and  its  components  are  maintained  at 
a  level  of  performance  and  reliability  indicated  by  the  organizational 
work  environment  standards.  As  required,  the  project’s  work 
environment  or  some  of  its  components  can  be  developed  internally  or 
acquired  from  external  sources. 


IPPD  Addition 

An  effective  work  environment  helps  projects  employing  IPPD  to  conduct 
work  using  collocated  or  distributed  integrated  teams.  Two-way 
communications  media  should  be  readily  accessible  by  all  relevant 
stakeholders  in  the  project. 


The  project’s  work  environment  might  encompass  environments  for 
product  integration,  verification,  and  validation  or  they  might  be 
separate  environments. 

Refer  to  the  Establish  Work  Environment  Standards  specific  practice  in 
the  Organizational  Process  Definition  process  area  for  more  information 
about  work  environment  standards. 

Refer  to  the  Establish  the  Product  Integration  Environment  specific 
practice  of  the  Product  Integration  process  area  for  more  information 
about  establishing  and  maintaining  the  product  integration  environment 
for  the  project. 

Refer  to  the  Establish  the  Verification  Environment  specific  practice  of 
the  Verification  process  area  for  more  information  about  establishing 
and  maintaining  the  verification  environment  for  the  project. 

Refer  to  the  Establish  the  Validation  Environment  specific  practice  of 
the  Validation  process  area  for  more  information  about  establishing  and 
maintaining  the  validation  environment  for  the  project. 

Typical  Work  Products 

1 .  Equipment  and  tools  for  the  project 

2.  Installation,  operation,  and  maintenance  manuals  for  the  project 
work  environment 

3.  User  surveys  and  results 

4.  Usage,  performance,  and  maintenance  records 


152 


Integrated  Project  Management  +IPPD  (IPM+IPPD) 


CMMI  for  Development 
Version  1.2 

5.  Support  services  for  the  project’s  work  environment 
Subpractices 

1 .  Plan,  design,  and  install  a  work  environment  for  the  project. 

The  critical  aspects  of  the  project  work  environment  are,  like  any  other  product, 
requirements  driven.  Work  environment  functionality  and  operations  are  explored 
with  the  same  rigor  as  is  done  for  any  other  product  development. 

It  may  be  necessary  to  make  tradeoffs  among  performance,  costs,  and  risks.  The 
I  following  are  examples  of  each: 

i  •  Performance  considerations  may  include  timely  interoperable  communications, 
safety,  security,  and  maintainability. 

:  •  Costs  may  include  capital  outlays,  training,  support  structure,  disassembly  and 
disposal  of  existing  environments,  and  operation  and  maintenance  of  the 
environment. 

•  Risks  may  include  workflow  and  project  disruptions. 

i  Examples  of  equipment  and  tools  include  the  following: 

|  •  Office  software 

:  •  Decision  support  software 

i  •  Project  management  tools 

|  •  Requirements  management  tools,  design  tools 

:  •  Configuration  management  tools 

i  •  Evaluation  tools 

•  Test  and/or  evaluation  equipment 

2.  Provide  ongoing  maintenance  and  operational  support  for  the 
project’s  work  environment. 

Maintenance  and  support  of  the  work  environment  can  be  accomplished  either 
with  capabilities  found  inside  the  organization  or  hired  from  outside  the 
organization. 

:  Examples  of  maintenance  and  support  approaches  include  the  following: 

|  •  Hiring  people  to  perform  the  maintenance  and  support 
|  •  Training  people  to  perform  the  maintenance  and  support 
:  •  Contracting  the  maintenance  and  support 

•  Developing  expert  users  for  selected  tools 

3.  Maintain  the  qualification  of  the  components  of  the  project’s  work 
environment. 
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Components  include  software,  databases,  hardware,  tools,  test  equipment,  and 
appropriate  documentation.  Qualification  of  software  includes  appropriate 
certifications.  Hardware  and  test  equipment  qualification  includes  calibration  and 
adjustment  records  and  traceability  to  calibration  standards. 

4.  Periodically  review  how  well  the  work  environment  is  meeting  the 
project’s  needs  and  supporting  collaboration,  and  take  action  as 
appropriate. 


Examples  of  actions  that  might  be  taken  include  the  following: 

•  Adding  new  tools 

•  Acquiring  additional  networks,  equipment,  training,  and  support 


SP  1.4  Integrate  Plans 

Integrate  the  project  plan  and  the  other  plans  that  affect  the 
project  to  describe  the  project’s  defined  process. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  a  project  plan. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and,  in  particular,  the 
organization’s  measurement  repository. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures  and  measurement  activities  and 
using  analytic  techniques. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives. 

This  specific  practice  extends  the  specific  practices  for  establishing  and 
maintaining  a  project  plan  to  address  additional  planning  activities  such 
as  incorporating  the  project’s  defined  process,  coordinating  with 
relevant  stakeholders,  using  organizational  process  assets, 
incorporating  plans  for  peer  reviews,  and  establishing  objective  entry 
and  exit  criteria  for  tasks. 

The  development  of  the  project  plan  should  account  for  current  and 
projected  needs,  objectives,  and  requirements  of  the  organization, 
customer,  suppliers,  and  end  users,  as  appropriate. 
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The  plans  of  the  integrated  teams  are  included  in  this  integration. 
Developing  a  complete  project  plan  and  the  project’s  defined  process  may 
require  an  iterative  effort  if  a  complex,  multi-layered,  integrated  team 
structure  is  being  deployed. 


Typical  Work  Products 

1.  Integrated  plans 

Subpractices 

1 .  Integrate  other  plans  that  affect  the  project  with  the  project  plan. 

Other  plans  that  affect  the  project  may  include  the  following: 

•  Quality  assurance  plans 

•  Configuration  management  plans 

•  Risk  management  strategy 

•  Documentation  plans 

2.  Incorporate  into  the  project  plan  the  definitions  of  measures  and 
measurement  activities  for  managing  the  project. 

:  Examples  of  measures  that  would  be  incorporated  include  the  following: 

|  •  Organization’s  common  set  of  measures 

•  Additional  project-specific  measures 

3.  Identify  and  analyze  product  and  project  interface  risks. 

;  Examples  of  product  and  project  interface  risks  include  the  following: 

|  •  Incomplete  interface  descriptions 
i  •  Unavailability  of  tools  or  test  equipment 
i  •  Availability  of  COTS  components 
:  •  Inadequate  or  ineffective  team  interfaces 

4.  Schedule  the  tasks  in  a  sequence  that  accounts  for  critical 
development  factors  and  project  risks. 
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Examples  of  factors  considered  in  scheduling  include  the  following: 

•  Size  and  complexity  of  the  tasks 

•  Integration  and  test  issues 

•  Needs  of  the  customer  and  end  users 

•  Availability  of  critical  resources 

•  Availability  of  key  personnel 


5.  Incorporate  the  plans  for  performing  peer  reviews  on  the  work 
products  of  the  project's  defined  process. 

Refer  to  the  Verification  process  area  for  more  information  about 
peer  reviews. 

6.  Incorporate  the  training  needed  to  perform  the  project’s  defined 
process  in  the  project’s  training  plans. 

This  task  typically  involves  negotiating  with  the  organizational  training  group  the 
support  they  will  provide. 

7.  Establish  objective  entry  and  exit  criteria  to  authorize  the  initiation 
and  completion  of  the  tasks  described  in  the  work  breakdown 
structure  (WBS). 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  the  WBS. 

8.  Ensure  that  the  project  plan  is  appropriately  compatible  with  the 
plans  of  relevant  stakeholders. 

Typically  the  plan  and  changes  to  the  plan  will  be  reviewed  for  compatibility. 

9.  Identify  how  conflicts  will  be  resolved  that  arise  among  relevant 
stakeholders. 


SP  1.5  Manage  the  Project  Using  the  Integrated  Plans 

Manage  the  project  using  the  project  plan,  the  other  plans  that 
affect  the  project,  and  the  project’s  defined  process. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives  and 
coordinating  process  improvement  activities  with  the  rest  of  the 
organization. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
managing  risks. 
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Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project. 

Typical  Work  Products 

1 .  Work  products  created  by  performing  the  project’s  defined  process 

2.  Collected  measures  (“actuals”)  and  progress  records  or  reports 

3.  Revised  requirements,  plans,  and  commitments 

4.  Integrated  plans 

Subpractices 

1 .  Implement  the  project’s  defined  process  using  the  organization's 
process  asset  library. 

This  task  typically  includes  the  following: 

•  Incorporating  artifacts  from  the  organization’s  process  asset  library  into  the  project 
as  appropriate 

•  Using  lessons  learned  from  the  organization’s  process  asset  library  to  manage  the 
project 

2.  Monitor  and  control  the  project’s  activities  and  work  products  using 
the  project’s  defined  process,  project  plan,  and  other  plans  that 
affect  the  project. 

This  task  typically  includes  the  following: 

•  Using  the  defined  entry  and  exit  criteria  to  authorize  the  initiation  and  determine 
the  completion  of  the  tasks 

•  Monitoring  the  activities  that  could  significantly  affect  the  actual  values  of  the 
project’s  planning  parameters 

•  Tracking  the  project’s  planning  parameters  using  measurable  thresholds  that  will 
trigger  investigation  and  appropriate  actions 

•  Monitoring  product  and  project  interface  risks 

•  Managing  external  and  internal  commitments  based  on  the  plans  for  the  tasks  and 
work  products  of  the  project’s  defined  process 

An  understanding  of  the  relationships  among  the  various  tasks  and  work  products 
of  the  project’s  defined  process,  and  of  the  roles  to  be  performed  by  the  relevant 
stakeholders,  along  with  well-defined  control  mechanisms  (e.g.,  peer  reviews) 
achieves  better  visibility  into  the  project’s  performance  and  better  control  of  the 
project. 

3.  Obtain  and  analyze  the  selected  measures  to  manage  the  project 
and  support  the  organization’s  needs. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  a  process  for  obtaining  and  analyzing 
measures. 
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4.  Periodically  review  and  align  the  project’s  performance  with  the 
current  and  anticipated  needs,  objectives,  and  requirements  of  the 
organization,  customer,  and  end  users,  as  appropriate. 

This  review  includes  alignment  with  the  organizational  process  needs  and 
objectives. 


Examples  of  actions  that  achieve  alignment  include  the  following: 

•  Accelerating  the  schedule,  with  appropriate  adjustments  to  other  planning 
parameters  and  the  project  risks 

•  Changing  the  requirements  in  response  to  a  change  in  market  opportunities  or 
customer  and  end-user  needs 

•  Terminating  the  project 


SP  1.6  Contribute  to  the  Organizational  Process  Assets 

Contribute  work  products,  measures,  and  documented 
experiences  to  the  organizational  process  assets. 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  process  improvement  proposals. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  the  organization’s 
measurement  repository,  and  the  organization’s  process  asset  library. 

This  specific  practice  addresses  collecting  information  from  processes 
in  the  project’s  defined  process. 

Typical  Work  Products 

1 .  Proposed  improvements  to  the  organizational  process  assets 

2.  Actual  process  and  product  measures  collected  from  the  project 

3.  Documentation  (e.g.,  exemplary  process  descriptions,  plans, 
training  modules,  checklists,  and  lessons  learned) 

4.  Process  artifacts  associated  with  tailoring  and  implementing  the 
organization’s  set  of  standard  processes  on  the  project 

Subpractices 

1 .  Propose  improvements  to  the  organizational  process  assets. 

2.  Store  process  and  product  measures  in  the  organization’s 
measurement  repository. 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  recording  planning  and  replanning  data. 
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Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  recording  measures. 

This  typically  includes  the  following: 

•  Planning  data 

•  Replanning  data 

•  Measures 

:  Examples  of  data  recorded  by  the  project  include  the  following: 

j  •  Task  descriptions 
j  •  Assumptions 
:  •  Estimates 
i  •  Revised  estimates 

j  •  Definitions  of  recorded  data  and  measures 
j  •  Measures 

:  •  Context  information  that  relates  the  measures  to  the  activities  performed  and  work 
:  products  produced 

j  •  Associated  information  needed  to  reconstruct  the  estimates,  assess  their 
reasonableness,  and  derive  estimates  for  new  work 

3.  Submit  documentation  for  possible  inclusion  in  the  organization's 
process  asset  library. 

Examples  of  documentation  include  the  following: 

j  •  Exemplary  process  descriptions 
:  •  Training  modules 
i  •  Exemplary  plans 

•  Checklists 


4.  Document  lessons  learned  from  the  project  for  inclusion  in  the 
organization's  process  asset  library. 

5.  Provide  process  artifacts  associated  with  tailoring  and 
implementing  the  organization’s  set  of  standard  processes  in 
support  of  the  organization’s  process  monitoring  activities. 

Refer  to  the  Monitor  Implementation  specific  practice  of  the 
Organization  Process  Focus  process  area  for  more  information 
about  the  organization’s  activities  to  understand  the  extent  of 
deployment  of  standard  processes  on  new  and  existing  projects. 
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SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 

Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  is 
conducted. 


SP  2.1  Manage  Stakeholder  Involvement 

Manage  the  involvement  of  the  relevant  stakeholders  in  the 
project. 


Stakeholder  involvement  is  managed  according  to  the  project’s 
integrated  and  defined  process. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  stakeholders  and  their  appropriate  involvement  and  about 
establishing  and  maintaining  commitments. 

Typical  Work  Products 

1 .  Agendas  and  schedules  for  collaborative  activities 

2.  Documented  issues  (e.g.,  issues  with  customer  requirements, 
product  and  product  component  requirements,  product 
architecture,  and  product  design) 

3.  Recommendations  for  resolving  relevant  stakeholder  issues 
Subpractices 

1.  Coordinate  with  the  relevant  stakeholders  who  should  participate  in 
the  project’s  activities. 

The  relevant  stakeholders  should  already  be  identified  in  the  project  plan. 

2.  Ensure  that  work  products  that  are  produced  to  satisfy 
commitments  meet  the  requirements  of  the  recipient  projects. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  work  products  against  their  requirements. 

This  task  typically  includes  the  following: 

•  Reviewing,  demonstrating,  or  testing,  as  appropriate,  each  work  product  produced 
by  relevant  stakeholders 

•  Reviewing,  demonstrating,  or  testing,  as  appropriate,  each  work  product  produced 
by  the  project  for  other  projects  with  representatives  of  the  projects  receiving  the 
work  product 

•  Resolving  issues  related  to  the  acceptance  of  the  work  products 

3.  Develop  recommendations  and  coordinate  the  actions  to  resolve 
misunderstandings  and  problems  with  the  product  and  product 
component  requirements,  product  and  product  component 
architecture,  and  product  and  product  component  design. 
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SP  2.2  Manage  Dependencies 

Participate  with  relevant  stakeholders  to  identify,  negotiate,  and 
track  critical  dependencies. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  stakeholders  and  their  appropriate  involvement  and  about 
establishing  and  maintaining  commitments. 

Typical  Work  Products 

1 .  Defects,  issues,  and  action  items  resulting  from  reviews  with 
relevant  stakeholders 

2.  Critical  dependencies 

3.  Commitments  to  address  critical  dependencies 

4.  Status  of  critical  dependencies 

Subpractices 

1 .  Conduct  reviews  with  relevant  stakeholders. 

2.  Identify  each  critical  dependency. 

3.  Establish  need  dates  and  plan  dates  for  each  critical  dependency 
based  on  the  project  schedule. 

4.  Review  and  get  agreement  on  the  commitments  to  address  each 
critical  dependency  with  the  people  responsible  for  providing  the 
work  product  and  the  people  receiving  the  work  product. 

5.  Document  the  critical  dependencies  and  commitments. 

Documentation  of  commitments  typically  includes  the  following: 

•  Describing  the  commitment 

•  Identifying  who  made  the  commitment 

•  Identifying  who  is  responsible  for  satisfying  the  commitment 

•  Specifying  when  the  commitment  will  be  satisfied 

•  Specifying  the  criteria  for  determining  if  the  commitment  has  been  satisfied 

6.  Track  the  critical  dependencies  and  commitments  and  take 
corrective  action  as  appropriate. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  commitments. 
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Tracking  the  critical  dependencies  typically  includes  the  following: 

•  Evaluating  the  effects  of  late  and  early  completion  for  impacts  on  future  activities 
and  milestones 

•  Resolving  actual  and  potential  problems  with  the  responsible  people  whenever 
possible 

•  Escalating  to  the  appropriate  managers  the  actual  and  potential  problems  not 
resolvable  with  the  responsible  people 

SP  2.3  Resolve  Coordination  Issues 

Resolve  issues  with  relevant  stakeholders. 

Examples  of  coordination  issues  include  the  following: 

:  •  Late  critical  dependencies  and  commitments 
i  •  Product  and  product  component  requirements  and  design  defects 
i  •  Product-level  problems 

•  Unavailability  of  critical  resources  or  personnel 


Typical  Work  Products 

1 .  Relevant  stakeholder  coordination  issues 

2.  Status  of  relevant  stakeholder  coordination  issues 

Subpractices 

1 .  Identify  and  document  issues. 

2.  Communicate  issues  to  the  relevant  stakeholders. 

3.  Resolve  issues  with  the  relevant  stakeholders. 

4.  Escalate  to  the  appropriate  managers  those  issues  not  resolvable 
with  the  relevant  stakeholders. 

5.  Track  the  issues  to  closure. 

6.  Communicate  with  the  relevant  stakeholders  on  the  status  and 
resolution  of  the  issues. 


IPPD  Addition 

SG  3  Apply  IPPD  Principles 

The  project  is  managed  using  IPPD  principles. 

The  purpose  of  this  specific  goal  and  its  practices  is  to  create  an  IPPD 
environment  that  enables  integrated  teams  to  efficiently  meet  the 
project’s  requirements  and  produce  a  quality  product. 
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SP  3.1  Establish  the  Project’s  Shared  Vision 

Establish  and  maintain  a  shared  vision  for  the  project. 

A  project  does  not  operate  in  isolation.  Understanding  organizational 
mission,  goals,  expectations  and  constraints  allows  the  project  to  align 
its  direction,  activities,  and  shared  vision  with  the  organization  and 
helps  create  a  common  purpose  within  which  project  activities  can  be 
coordinated.  To  enable  this,  it  is  critical  to  understand  the  interfaces 
between  the  project  and  stakeholders  external  to  the  project  and  the 
objectives  and  expectations  of  all  relevant  stakeholders  (internal  and 
external). 

When  creating  a  shared  vision,  consider: 

•  external  stakeholder  expectations  and  requirements 

•  the  aspirations  and  expectations  of  the  project  leader,  team  leaders, 
and  team  members 

•  the  project’s  objectives 

•  the  conditions  and  outcomes  the  project  will  create 

•  interfaces  the  project  needs  to  maintain 

•  the  visions  created  by  interfacing  groups 

•  the  constraints  imposed  by  outside  authorities  (e.g.,  environmental 
regulations) 

•  project  operation  while  working  to  achieve  its  objectives  (both 
principles  and  behaviors) 

When  creating  a  shared  vision,  all  people  in  the  project  should  be 
invited  to  participate.  Although  there  may  be  a  draft  proposal,  the  larger 
population  must  have  an  opportunity  to  speak  and  be  heard  about  what 
really  matters  to  them.  The  shared  vision  is  articulated  in  terms  of  both 
the  core  ideology  (values,  principles,  and  behaviors)  and  the  desired 
future  to  which  each  member  of  the  project  can  commit. 

An  effective  communications  strategy  is  key  to  implementing  and 
focusing  the  shared  vision  throughout  the  project.  Promulgation  of  the 
shared  vision  is  a  public  declaration  of  the  commitment  of  the  project  to 
their  shared  vision  and  provides  the  opportunity  for  others  to  examine, 
understand,  and  align  their  activities  in  a  common  direction.  The  shared 
vision  should  be  communicated,  and  agreement  and  commitment  of  the 
relevant  stakeholders  should  be  obtained. 
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Effective  communications  are  also  especially  important  when 
incorporating  new  project  members.  New  members  of  the  project  often 
need  more  or  special  attention  to  ensure  that  they  understand  the 
shared  vision,  have  a  stake  in  it,  and  are  prepared  to  follow  it  in  doing 
their  work. 

Typical  Work  Products 

1.  Documented  shared  vision 

2.  Communications  strategy 

3.  Published  principles,  shared  vision  statement,  mission  statement, 
and  objectives  (e.g.,  posters,  wallet  cards,  and  presentations) 

Subpractices 

1 .  Articulate  the  project’s  shared  vision  in  terms  of  purpose  or 
mission,  vision,  values,  and  objectives. 

2.  Reach  consensus  on  the  project’s  shared  vision. 

3.  Establish  a  strategy  to  communicate  the  project’s  shared  vision 
both  externally  and  internally. 

4.  Create  presentations  suitable  for  the  various  audiences  that  need 
to  be  informed  about  the  project’s  shared  vision. 

5.  Ensure  that  project  and  individual  activities  and  tasks  are  aligned 
with  the  project’s  shared  vision. 

SP  3.2  Establish  the  Integrated  Team  Structure 

Establish  and  maintain  the  integrated  team  structure  for  the 
project. 

Product  requirements,  cost,  schedule,  risk,  resource  projections, 
business  processes,  the  project’s  defined  process,  and  organizational 
guidelines  are  evaluated  to  establish  the  basis  for  defining  integrated 
teams  and  their  responsibilities,  authorities,  and  interrelationships. 

A  typical  integrated  team  structure  may  be  based  on  the  product- 
oriented  hierarchy  found  in  the  WBS.  More  complex  structuring  occurs 
when  the  WBS  is  not  product  oriented,  product  risks  are  not  uniform, 
and  resources  are  constrained. 


The  integrated  team  structure  is  a  dynamic  entity  that  is  adjusted  to 
changes  in  people,  requirements,  and  the  nature  of  tasks,  and  to  tackle 
many  difficulties.  For  small  projects,  the  integrated  team  structure  can 
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treat  the  whole  project  as  an  integrated  team.  The  integrated  team 
structure  should  be  continuously  monitored  to  detect  malfunctions, 
mismanaged  interfaces,  and  mismatches  of  the  work  to  the  staff. 
Corrective  action  should  be  taken  when  performance  does  not  meet 
expectations. 

Refer  to  the  Establish  Rules  and  Guidelines  for  Integrated  Teams 
specific  practice  in  the  Organizational  Process  Definition  +IPPD  process 
area  for  more  information  about  establishing  organizational  rules  and 
guidelines  for  structuring  and  forming  integrated  teams. 

Typical  Work  Products 

1 .  Assessments  of  the  product  and  product  architectures,  including 
risk  and  complexity 

2.  Integrated  team  structure 
Subpractices 

1.  Establish  an  integrated  team  structure. 

An  integrated  team  structure  is  dependent  on: 

•  An  assessment  of  product  risk  and  complexity 

•  Location  and  types  of  risks 

•  Integration  risks,  including  product  component  interfaces  and  inter-team 
communication 

•  Resources,  including  availability  of  appropriately  skilled  people 

•  Limitations  on  team  size  for  effective  collaboration 

•  Need  for  team  membership  of  stakeholders  external  to  the  project 

•  Business  processes 

•  Organizational  structure 

The  integrated  team  structure  should  be  based  on  an  understanding  of  the 
project’s  defined  process  and  shared  vision,  the  organization’s  standard 
processes,  and  the  organizational  process  assets  applicable  to  teams  and  team 
structures. 

2.  Periodically  evaluate  and  modify  the  integrated  team  structure  to 
best  meet  project  needs. 

Changes  to  the  product  requirements  or  architecture  could  affect  the  team 
structure. 
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Continuously  monitor  the  integrated  team  structure  to  detect  problems  such  as 
mismanaged  interfaces,  and  mismatches  between  the  work  assigned  and  the  staff 
performing  the  work.  Take  corrective  action,  including  assessing  the  deployed 
teams  and  structures,  when  performance  does  not  meet  expectations. 

Changes  in  team  structure  can  include  the  following: 

•  Retiring  a  team  for  a  period  of  time  (e.g.,  while  long-duration  manufacturing  or 
verifications  are  done) 

•  Disbanding  a  team  when  it  is  no  longer  cost  effective  in  serving  the  project 

•  Combining  teams  to  achieve  operating  efficiencies 

•  Adding  teams  as  new  product  components  are  identified  for  development 

SP  3.3  Allocate  Requirements  to  Integrated  Teams 

Allocate  requirements,  responsibilities,  tasks,  and  interfaces  to 
teams  in  the  integrated  team  structure. 

This  allocation  of  requirements  to  integrated  teams  is  done  before  any 
teams  are  formed  to  verify  that  the  integrated  team  structure  is 
workable  and  covers  all  the  necessary  requirements,  responsibilities, 
authorities,  tasks,  and  interfaces.  Once  the  structure  is  confirmed, 
integrated  team  sponsors  are  chosen  to  establish  the  individual  teams 
in  the  structure. 

Typical  Work  Products 

1 .  Responsibilities  allocated  to  each  integrated  team 

2.  Work  product  requirements,  technical  interfaces,  and  business 
(e.g.,  cost  accounting  and  project  management)  interfaces  each 
integrated  team  will  be  responsible  for  satisfying 

3.  List  of  integrated  team  sponsors 
Subpractices 

1 .  Allocate  the  tasks,  responsibilities,  and  work  products  to  be 

delivered,  and  the  associated  requirements  and  interfaces  to  the 
appropriate  integrated  teams. 

Business,  management,  and  other  nontechnical  responsibilities  and  authorities  for 
each  integrated  team  are  necessary  elements  to  proper  team  function.  Integrated 
team  responsibilities  and  authorities  are  normally  developed  by  the  project  and 
are  consistent  with  established  organization  practices. 
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Example  responsibilities  and  authorities,  include  the  following: 

|  •  Authority  of  teams  to  pick  their  own  leader 

:  •  Authority  of  teams  to  implement  subteams  (e.g.,  a  product  team  forming  an 
:  integration  subteam) 

i  •  Reporting  chains 

|  •  Reporting  requirements  (cost,  schedule,  and  performance  status) 

•  Progress  reporting  measures  and  methods 


2.  Check  that  the  distribution  of  requirements  and  interfaces  covers 
all  specified  product  requirements  and  other  requirements. 

In  the  event  that  complete  coverage  of  requirements  is  not  achieved,  corrective 
action  should  be  taken  to  redistribute  requirements  or  to  alter  the  integrated  team 
structure. 

3.  Designate  the  sponsor  for  each  integrated  team. 

An  integrated  team  sponsor  is  a  manager  (individual  or  team)  who  is  responsible 
for  establishing  and  providing  resources  to  an  integrated  team,  monitoring  its 
activities  and  progress,  and  taking  corrective  action  when  needed.  A  sponsor  may 
manage  one  or  many  teams.  Team  sponsors  can  be  project  managers. 

SP  3.4  Establish  Integrated  Teams 

Establish  and  maintain  integrated  teams  in  the  structure. 

The  integrated  teams  within  the  integrated  team  structure  are 
established  by  the  team  sponsors.  This  process  encompasses  choosing 
team  leaders  and  team  members,  and  establishing  the  team  charter  for 
each  integrated  team  based  on  the  allocation  of  requirements.  It  also 
involves  providing  the  resources  required  to  accomplish  the  tasks 
assigned  to  the  team. 

Refer  to  the  Establish  Rules  and  Guidelines  for  Integrated  Teams 
specific  practice  in  the  Organizational  Process  Definition  +IPPD  process 
area  for  more  information  about  establishing  organizational  rules  and 
guidelines  for  structuring  and  forming  integrated  teams. 

Typical  Work  Products 

1 .  List  of  team  leaders 

2.  List  of  team  members  assigned  to  each  integrated  team 

3.  Integrated  team  charters 

4.  Measures  for  evaluating  the  performance  of  integrated  teams 
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5.  Periodic  integrated  team  status  reports 
Subpractices 

1 .  Choose  a  leader  for  each  integrated  team. 

The  extent  of  organizational  and  project  direction  in  selecting  the  leader  is  often  a 
function  of  product  risk  and  complexity  or  an  organization’s  need  to  “grow”  new 
leaders.  Team  sponsors  may  select  the  team  leader  or  team  members  may  vote 
on  a  leader  from  within  the  team,  depending  on  organizational  policies. 

2.  Allocate  resources  to  each  integrated  team. 

The  people  and  other  resources  are  allocated  to  each  integrated  team.  These 
items  are  discussed  with  the  team  to  ensure  that  the  resources  are  adequate  and 
that  the  people  are  adequate  to  carry  out  the  tasks  and  are  compatible  with  other 
members  of  the  team. 

3.  Charter  each  integrated  team. 

The  team  charter  is  the  contract  among  the  team  members  and  between  the  team 
and  its  sponsor  for  the  expected  work  and  level  of  performance.  Charters 
establish  the  rights,  guarantees,  privileges,  and  permissions  for  organizing  and 
performing  the  team’s  assigned  requirements  and  interfaces,  responsibilities  and 
tasks.  The  integrated  team  and  its  sponsor  develop  the  team  charter  as  a 
negotiation  activity.  When  both  approve  it,  the  team  charter  constitutes  a 
recognized  agreement  with  management  authority. 

Charters  can  include  the  following  aspects: 

•  How  assignments  are  accepted 

•  How  resources  and  input  are  accessed 

•  How  work  gets  done 

•  Who  checks  and  reviews  work 

•  How  work  is  approved 

•  How  work  is  delivered  and  communicated 

4.  Review  the  composition  of  an  integrated  team  and  its  place  in  the 
integrated  team  structure  when  its  team  leader  changes  or  another 
significant  change  of  membership  occurs. 

A  change  of  this  kind  may  significantly  affect  the  ability  of  the  team  to  accomplish 
its  objectives.  A  review  of  the  match  between  the  new  composition  and  the  current 
responsibilities  should  be  made.  If  the  match  is  not  satisfactory,  the  team 
composition  should  be  changed  or  the  team’s  responsibility  should  be  modified. 

5.  Review  the  composition  of  a  team  and  its  tasking  when  a  change  in 
team  responsibility  occurs. 
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Changes  in  responsibilities  often  occur  as  the  project  moves  from  one  phase  to 
the  next.  For  example,  less  design  expertise  on  teams  may  be  needed  when 
detailed  design  is  completed  and  fabrication  and  integration  of  product 
components  begins. 

6.  Manage  the  overall  performance  of  the  teams. 

The  charter  should  specify  how  both  team  and  individual  performance  will  be 
measured  and  should  include  the  critical  success  factors  for  the  team  within  the 
project. 

SP  3.5  Ensure  Collaboration  among  Interfacing  Teams 

Ensure  collaboration  among  interfacing  teams. 

The  success  of  an  integrated  team-based  project  is  a  function  of  how 
effectively  and  successfully  the  integrated  teams  collaborate  with  one 
another  to  achieve  project  objectives.  This  collaboration  may  be 
accomplished  using  interface  control  working  groups. 

See  the  Coordinate  and  Collaborate  with  Relevant  Stakeholders 
specific  goal  of  this  process  area  for  more  information  about  managing 
stakeholder  involvement,  critical  dependencies,  and  resolving 
coordination  issues. 

Refer  to  the  Establish  Rules  and  Guidelines  for  Integrated  Teams 
specific  practice  in  the  Organizational  Process  Definition  +IPPD  process 
area  for  more  information  about  establishing  organizational 
expectations  and  rules  that  will  guide  how  the  integrated  teams  work 
collectively. 

Typical  Work  Products 

1 .  Work  product  ownership  agreements 

2.  Team  work  plans 

3.  Commitment  lists 

Subpractices 

1 .  Establish  and  maintain  the  boundaries  of  work  product  ownership 
among  interfacing  teams  within  the  project  or  organization. 

2.  Establish  and  maintain  interfaces  and  processes  among  interfacing 
teams  for  the  exchange  of  inputs,  outputs,  or  work  products. 

3.  Develop,  communicate,  and  distribute  among  interfacing  teams  the 
commitment  lists  and  work  plans  that  are  related  to  work  product  or 
team  interfaces. 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1 

Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  integrated  project 
management  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  integrated  project  management  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  the  project’s  defined  process  from  project  startup  through 
the  life  of  the  project,  using  the  project’s  defined  process  in  managing 
the  project,  and  coordinating  and  collaborating  with  relevant 
stakeholders. 


IPPD  Addition 

This  policy  also  establishes  organizational  expectations  for  applying  IPPD 
principles. 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  integrated 
project  management  process. 


Elaboration: 

This  plan  for  the  integrated  project  management  process  unites  the 
planning  for  the  project  planning  and  monitor  and  control  processes. 
The  planning  for  performing  the  planning-related  practices  in  Integrated 
Project  Management  is  addressed  as  part  of  planning  the  project 
planning  process.  This  plan  for  performing  the  monitor-and-control- 
related  practices  in  Integrated  Project  Management  can  be  included  in 
(or  referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area. 


Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.2 
and  project  planning  processes. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  integrated 
project  management  process,  developing  the  work  products, 
and  providing  the  services  of  the  process. 

Elaboration: 

■  Examples  of  resources  provided  include  the  following  tools: 

:  •  Problem-tracking  and  trouble-reporting  packages 

:  •  Groupware 

:  •  Video  conferencing 

:  •  Integrated  decision  database 

•  Integrated  product  support  environments 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  integrated  project  management  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  integrated 
project  management  process  as  needed. 
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Elaboration: 

:  Examples  of  training  topics  include  the  following: 

I  •  Tailoring  the  organization’s  set  of  standard  processes  to  meet  the  needs  of  the 
:  project 

i  •  Procedures  for  managing  the  project  based  on  the  project’s  defined  process 
:  •  Using  the  organization’s  measurement  repository 

:  •  Using  the  organizational  process  assets 

i  •  Integrated  management 

:  •  Intergroup  coordination 

•  Group  problem  solving 


IPPD  Addition 

Examples  of  training  topics  also  include  the  following: 

•  Building  the  project's  shared  vision 

•  Team  building 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  integrated  project 
management  process  under  appropriate  levels  of  control. 

Elaboration: 

:  Examples  of  work  products  placed  under  control  include  the  following: 
j  •  The  project’s  defined  process 

j  •  Project  plans 

:  •  Other  plans  that  affect  the  project 
:  •  Integrated  plans 

•  Actual  process  and  product  measures  collected  from  the  project 


IPPD  Addition 

Examples  of  work  products  placed  under  control  also  include  the  following: 

•  Project's  shared  vision 

•  Integrated  team  structure 

•  Integrated  team  charters 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  integrated 
project  management  process  as  planned. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.7 
and  the  Manage  Stakeholder  Involvement  practice  in  this  process  area. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Resolving  issues  about  the  tailoring  of  the  organizational  process  assets 

•  Resolving  issues  among  the  project  plan  and  the  other  plans  that  affect  the  project 

•  Reviewing  project  performance  to  align  with  current  and  projected  needs, 
objectives,  and  requirements 


IPPD  Addition 

Examples  of  activities  for  stakeholder  involvement  also  include  the 
following: 

•  Creating  the  project's  shared  vision 

•  Defining  the  integrated  team  structure  for  the  project 

•  Populating  the  integrated  teams 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  integrated  project  management 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  changes  to  the  project’s  defined  process 

•  Schedule  and  effort  to  tailor  the  organization’s  set  of  standard  processes 

•  Interface  coordination  issue  trends  (i.e.,  number  identified  and  number  closed) 

•  Schedule  for  project  tailoring  activities 
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Examples  of  measures  and  work  products  used  in  monitoring  and 
controlling  also  include  the  following: 

•  Project's  shared  vision  usage  and  effectiveness 

•  Integrated  team-structure  usage  and  effectiveness 

•  Integrated  team  charters  usage  and  effectiveness 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  integrated  project 
management  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 


Elaboration: 


Examples  of  activities  reviewed  include  the  following: 

•  Establishing,  maintaining,  and  using  the  project’s  defined  process 

•  Coordinating  and  collaborating  with  relevant  stakeholders 


IPPD  Addition 

Examples  of  activities  reviewed  also  include  the  following: 

•  Using  the  project's  shared  vision 

•  Organizing  integrated  teams 

Examples  of  work  products  reviewed  include  the  following: 

•  Project’s  defined  process 

•  Project  plans 

•  Other  plans  that  affect  the  project 


IPPD  Addition 

Examples  of  work  products  reviewed  also  include  the  following: 

•  Integrated  team  structure 

•  Integrated  team  charters 

•  Shared  vision  statements 
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GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  integrated 
project  management  process  with  higher  level  management 
and  resolve  issues. 


Continuous  Only 

GG  3  institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  integrated 
project  management  process. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  3.1 
and  the  Integrated  Project  Management  process  area. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  integrated  project  management  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  3.2 
and  the  Integrated  Project  Management  process  area. 
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Examples  of  work  products,  measures,  measurement  results,  and  improvement 

information  include  the  following: 

•  Project’s  defined  process 

•  Number  of  tailoring  options  exercised  by  the  project  to  create  its  defined  process 

•  interface  coordination  issue  trends  (i.e.,  number  identified  and  number  closed) 

•  Number  of  times  the  PAL  is  accessed  for  assets  related  to  project  planning  by 
project  personnel 

•  Records  of  expenses  related  to  holding  face-to-face  meetings  versus  holding 
meetings  using  collaborative  equipment  such  as  teleconferencing  and 
videoconferencing 


IPPD  Addition 

Examples  of  work  products,  measures,  measurement  results,  and 
improvement  information  also  include  the  following: 

•  Integrated  team  charters 

•  Project  shared  vision 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
integrated  project  management  process,  which  address  quality 
and  process  performance,  based  on  customer  needs  and 
business  objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  integrated  project  management 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  integrated  project 
management  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 
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Continuous  Only 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  integrated  project  management  process. 
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MEASUREMENT  AND  ANALYSIS 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Measurement  and  Analysis  (MA)  is  to  develop  and 
sustain  a  measurement  capability  that  is  used  to  support  management 
information  needs. 


Introductory  Notes 


The  Measurement  and  Analysis  process  area  involves  the  following: 

•  Specifying  the  objectives  of  measurement  and  analysis  such  that 
they  are  aligned  with  identified  information  needs  and  objectives 

•  Specifying  the  measures,  analysis  techniques,  and  mechanism  for 
data  collection,  data  storage,  reporting,  and  feedback 

•  Implementing  the  collection,  storage,  analysis,  and  reporting  of  the 
data 

•  Providing  objective  results  that  can  be  used  in  making  informed 
decisions,  and  taking  appropriate  corrective  actions 

The  integration  of  measurement  and  analysis  activities  into  the 
processes  of  the  project  supports  the  following: 

•  Objective  planning  and  estimating 

•  Tracking  actual  performance  against  established  plans  and 
objectives 

•  Identifying  and  resolving  process-related  issues 

•  Providing  a  basis  for  incorporating  measurement  into  additional 
processes  in  the  future 

The  staff  required  to  implement  a  measurement  capability  may  or  may 
not  be  employed  in  a  separate  organization-wide  program. 
Measurement  capability  may  be  integrated  into  individual  projects  or 
other  organizational  functions  (e.g.,  quality  assurance). 

The  initial  focus  for  measurement  activities  is  at  the  project  level. 
However,  a  measurement  capability  may  prove  useful  for  addressing 
organization-  and/or  enterprise-wide  information  needs.  To  support  this 
capability,  the  measurement  activities  should  support  information  needs 
at  multiple  levels  including  the  business,  organizational  unit,  and  project 
to  minimize  re-work  as  the  organization  matures. 
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Projects  may  choose  to  store  project-specific  data  and  results  in  a 
project-specific  repository.  When  data  are  shared  more  widely  across 
projects,  the  data  may  reside  in  the  organization’s  measurement 
repository. 

Measurement  and  analysis  of  the  product  components  provided  by 
suppliers  is  essential  for  effective  management  of  the  quality  and  costs 
of  the  project.  It  is  possible,  with  careful  management  of  supplier 
agreements,  to  provide  insight  into  the  data  that  support  supplier- 
performance  analysis. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
estimating  project  attributes  and  other  planning  information  needs. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  performance  information  needs. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  managing  measurement  work  products. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  meeting  customer  requirements  and  related 
information  needs. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability  and  related 
information  needs. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  the  organization’s  measurement 
repository. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  understanding  variation  and  the  appropriate  use  of 
statistical  analysis  techniques. 

Specific  Goal  and  Practice  Summary 

SG  1  Align  Measurement  and  Analysis  Activities 
SP  1.1  Establish  Measurement  Objectives 
SP  1 .2  Specify  Measures 

SP  1 .3  Specify  Data  Collection  and  Storage  Procedures 

SP  1 .4  Specify  Analysis  Procedures 

SG  2  Provide  Measurement  Results 

SP2.1  Collect  Measurement  Data 
SP  2.2  Analyze  Measurement  Data 
SP  2.3  Store  Data  and  Results 
SP  2.4  Communicate  Results 
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Specific  Practices  by  Goal 


SG  1  Align  Measurement  and  Analysis  Activities 

Measurement  objectives  and  activities  are  aligned  with  identified 
information  needs  and  objectives. 

The  specific  practices  covered  under  this  specific  goal  may  be 
addressed  concurrently  or  in  any  order: 

•  When  establishing  measurement  objectives,  experts  often  think 
ahead  about  necessary  criteria  for  specifying  measures  and 
analysis  procedures.  They  also  think  concurrently  about  the 
constraints  imposed  by  data  collection  and  storage  procedures. 

•  It  often  is  important  to  specify  the  essential  analyses  that  will  be 
conducted  before  attending  to  details  of  measurement  specification, 
data  collection,  or  storage. 

SP  1.1  Establish  Measurement  Objectives 

Establish  and  maintain  measurement  objectives  that  are 
derived  from  identified  information  needs  and  objectives. 


Measurement  objectives  document  the  purposes  for  which 
measurement  and  analysis  are  done,  and  specify  the  kinds  of  actions 
that  may  be  taken  based  on  the  results  of  data  analyses. 

The  sources  for  measurement  objectives  may  be  management, 
technical,  project,  product,  or  process  implementation  needs. 

The  measurement  objectives  may  be  constrained  by  existing 
processes,  available  resources,  or  other  measurement  considerations. 
Judgments  may  need  to  be  made  about  whether  the  value  of  the  results 
will  be  commensurate  with  the  resources  devoted  to  doing  the  work. 

Modifications  to  identified  information  needs  and  objectives  may,  in 
turn,  be  indicated  as  a  consequence  of  the  process  and  results  of 
measurement  and  analysis. 

Sources  of  information  needs  and  objectives  may  include  the  following: 

•  Project  plans 

•  Monitoring  of  project  performance 

•  Interviews  with  managers  and  others  who  have  information  needs 

•  Established  management  objectives 

•  Strategic  plans 

•  Business  plans 
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•  Formal  requirements  or  contractual  obligations 

•  Recurring  or  other  troublesome  management  or  technical  problems 

•  Experiences  of  other  projects  or  organizational  entities 

•  External  industry  benchmarks 

•  Process  improvement  plans 

Example  measurement  objectives  include  the  following: 

•  Reduce  time  to  delivery 

•  Reduce  total  lifecycle  cost 

•  Deliver  specified  functionality  completely 

•  Improve  prior  levels  of  quality 

•  Improve  prior  customer  satisfaction  ratings 

•  Maintain  and  improve  the  acquirer/supplier  relationships 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
estimating  project  attributes  and  other  planning  information  needs. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  project  performance  information  needs. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  meeting  customer  requirements  and  related 
information  needs. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability  and  related 
information  needs. 

Typical  Work  Products 

1 .  Measurement  objectives 

Subpractices 

1 .  Document  information  needs  and  objectives. 

Information  needs  and  objectives  are  documented  to  allow  traceability  to 
subsequent  measurement  and  analysis  activities. 

2.  Prioritize  information  needs  and  objectives. 

It  may  be  neither  possible  nor  desirable  to  subject  all  initially  identified  information 
needs  to  measurement  and  analysis.  Priorities  may  also  need  to  be  set  within  the 
limits  of  available  resources. 

3.  Document,  review,  and  update  measurement  objectives. 
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It  is  important  to  carefully  consider  the  purposes  and  intended  uses  of 
measurement  and  analysis. 

The  measurement  objectives  are  documented,  reviewed  by  management  and 
other  relevant  stakeholders,  and  updated  as  necessary.  Doing  so  enables 
traceability  to  subsequent  measurement  and  analysis  activities,  and  helps  ensure 
that  the  analyses  will  properly  address  identified  information  needs  and 
objectives. 

It  is  important  that  users  of  measurement  and  analysis  results  be  involved  in 
setting  measurement  objectives  and  deciding  on  plans  of  action.  It  may  also  be 
appropriate  to  involve  those  who  provide  the  measurement  data. 

4.  Provide  feedback  for  refining  and  clarifying  information  needs  and 
objectives  as  necessary. 

Identified  information  needs  and  objectives  may  need  to  be  refined  and  clarified 
as  a  result  of  setting  measurement  objectives.  Initial  descriptions  of  information 
needs  may  be  unclear  or  ambiguous.  Conflicts  may  arise  between  existing  needs 
and  objectives.  Precise  targets  on  an  already  existing  measure  may  be 
unrealistic. 

5.  Maintain  traceability  of  the  measurement  objectives  to  the  identified 
information  needs  and  objectives. 

There  must  always  be  a  good  answer  to  the  question,  “Why  are  we  measuring 
this?” 

Of  course,  the  measurement  objectives  may  also  change  to  reflect  evolving 
information  needs  and  objectives. 

SP  1.2  Specify  Measures 

Specify  measures  to  address  the  measurement  objectives. 


Measurement  objectives  are  refined  into  precise,  quantifiable 
measures. 

Measures  may  be  either  “base”  or  “derived.”  Data  for  base  measures 
are  obtained  by  direct  measurement.  Data  for  derived  measures  come 
from  other  data,  typically  by  combining  two  or  more  base  measures. 


Examples  of  commonly  used  base  measures  include  the  following: 

•  Estimates  and  actual  measures  of  work  product  size  (e.g.,  number  of  pages) 

•  Estimates  and  actual  measures  of  effort  and  cost  (e.g.,  number  of  person  hours) 

•  Quality  measures  (e.g.,  number  of  defects  by  severity) 
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Examples  of  commonly  used  derived  measures  include  the  following: 

•  Earned  Value 

•  Schedule  Performance  Index 

•  Defect  density 

•  Peer  review  coverage 

•  Test  or  verification  coverage 

•  Reliability  measures  (e.g.,  mean  time  to  failure) 

•  Quality  measures  (e.g.,  number  of  defects  by  severity/totai  number  of  defects) 


Derived  measures  typically  are  expressed  as  ratios,  composite  indices, 
or  other  aggregate  summary  measures.  They  are  often  more 
quantitatively  reliable  and  meaningfully  interpretable  than  the  base 
measures  used  to  generate  them. 

Typical  Work  Products 

1 .  Specifications  of  base  and  derived  measures 
Subpractices 

1.  Identify  candidate  measures  based  on  documented  measurement 
objectives. 

The  measurement  objectives  are  refined  into  specific  measures.  The  identified 
candidate  measures  are  categorized  and  specified  by  name  and  unit  of  measure. 

2.  Identify  existing  measures  that  already  address  the  measurement 
objectives. 

Specifications  for  measures  may  already  exist,  perhaps  established  for  other 
purposes  earlier  or  elsewhere  in  the  organization. 

3.  Specify  operational  definitions  for  the  measures. 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They 
address  two  important  criteria  as  follows: 

•  Communication:  What  has  been  measured,  how  was  it  measured,  what  are  the 
units  of  measure,  and  what  has  been  included  or  excluded? 

•  Repeatability:  Can  the  measurement  be  repeated,  given  the  same  definition,  to 
get  the  same  results? 

4.  Prioritize,  review,  and  update  measures. 

Proposed  specifications  of  the  measures  are  reviewed  for  their  appropriateness 
with  potential  end  users  and  other  relevant  stakeholders.  Priorities  are  set  or 
changed,  and  specifications  of  the  measures  are  updated  as  necessary. 
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SP  1.3  Specify  Data  Collection  and  Storage  Procedures 

Specify  how  measurement  data  will  be  obtained  and  stored. 

Explicit  specification  of  collection  methods  helps  ensure  that  the  right 
data  are  collected  properly.  It  may  also  aid  in  further  clarifying 
information  needs  and  measurement  objectives. 

Proper  attention  to  storage  and  retrieval  procedures  helps  ensure  that 
data  are  available  and  accessible  for  future  use. 

Typical  Work  Products 

1.  Data  collection  and  storage  procedures 

2.  Data  collection  tools 

Subpractices 

1 .  Identify  existing  sources  of  data  that  are  generated  from  current 
work  products,  processes,  or  transactions. 

Existing  sources  of  data  may  already  have  been  identified  when  specifying  the 
measures.  Appropriate  collection  mechanisms  may  exist  whether  or  not  pertinent 
data  have  already  been  collected. 

2.  Identify  measures  for  which  data  are  needed,  but  are  not  currently 
available. 

3.  Specify  how  to  collect  and  store  the  data  for  each  required 
measure. 

Explicit  specifications  are  made  of  how,  where,  and  when  the  data  will  be 
collected.  Procedures  for  collecting  valid  data  are  specified.  The  data  are  stored  in 
an  accessible  manner  for  analysis,  and  it  is  determined  whether  they  will  be  saved 
for  possible  reanalysis  or  documentation  purposes. 

Questions  to  be  considered  typically  include  the  following: 

•  Have  the  frequency  of  collection  and  the  points  in  the  process  where 
measurements  will  be  made  been  determined? 

•  Has  the  timeline  that  is  required  to  move  measurement  results  from  the  points  of 
collection  to  repositories,  other  databases,  or  end  users  been  established? 

•  Who  is  responsible  for  obtaining  the  data? 

•  Who  is  responsible  for  data  storage,  retrieval,  and  security? 

•  Have  necessary  supporting  tools  been  developed  or  acquired? 

4.  Create  data  collection  mechanisms  and  process  guidance. 

Data  collection  and  storage  mechanisms  are  well  integrated  with  other  normal 
work  processes.  Data  collection  mechanisms  may  include  manual  or  automated 
forms  and  templates.  Clear,  concise  guidance  on  correct  procedures  is  available 
to  those  responsible  for  doing  the  work.  Training  is  provided  as  necessary  to 
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clarify  the  processes  necessary  for  collection  of  complete  and  accurate  data  and 
to  minimize  the  burden  on  those  who  must  provide  and  record  the  data. 

5.  Support  automatic  collection  of  the  data  where  appropriate  and 
feasible. 

Automated  support  can  aid  in  collecting  more  complete  and  accurate  data. 


;  Examples  of  such  automated  support  include  the  following: 

|  •  Time  stamped  activity  logs 
•  Static  or  dynamic  analyses  of  artifacts 


However,  some  data  cannot  be  collected  without  human  intervention  (e.g., 
customer  satisfaction  or  other  human  judgments),  and  setting  up  the  necessary 
infrastructure  for  other  automation  may  be  costly. 

6.  Prioritize,  review,  and  update  data  collection  and  storage 
procedures. 

Proposed  procedures  are  reviewed  for  their  appropriateness  and  feasibility  with 
those  who  are  responsible  for  providing,  collecting,  and  storing  the  data.  They 
also  may  have  useful  insights  about  how  to  improve  existing  processes,  or  be 
able  to  suggest  other  useful  measures  or  analyses. 

7.  Update  measures  and  measurement  objectives  as  necessary. 

Priorities  may  need  to  be  reset  based  on  the  following: 

•  The  importance  of  the  measures 

•  The  amount  of  effort  required  to  obtain  the  data 

Considerations  include  whether  new  forms,  tools,  or  training  would  be  required  to 
obtain  the  data. 

SP  1.4  Specify  Analysis  Procedures 

Specify  how  measurement  data  will  be  analyzed  and  reported. 


Specifying  the  analysis  procedures  in  advance  ensures  that  appropriate 
analyses  will  be  conducted  and  reported  to  address  the  documented 
measurement  objectives  (and  thereby  the  information  needs  and 
objectives  on  which  they  are  based).  This  approach  also  provides  a 
check  that  the  necessary  data  will  in  fact  be  collected. 

Typical  Work  Products 

1.  Analysis  specifications  and  procedures 

2.  Data  analysis  tools 
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Subpractices 

1 .  Specify  and  prioritize  the  analyses  that  will  be  conducted  and  the 
reports  that  will  be  prepared. 

Early  attention  should  be  paid  to  the  analyses  that  will  be  conducted  and  to  the 
manner  in  which  the  results  will  be  reported.  These  should  meet  the  following 
criteria: 

•  The  analyses  explicitly  address  the  documented  measurement  objectives 

•  Presentation  of  the  results  is  clearly  understandable  by  the  audiences  to  whom 
the  results  are  addressed 

Priorities  may  have  to  be  set  within  available  resources. 

2.  Select  appropriate  data  analysis  methods  and  tools. 

Refer  to  the  Select  Measures  and  Analytic  Techniques  and  Apply 
Statistical  Methods  to  Understand  Variation  specific  practices  of 
the  Quantitative  Project  Management  process  area  for  more 
information  about  the  appropriate  use  of  statistical  analysis 
techniques  and  understanding  variation,  respectively. 

Issues  to  be  considered  typically  include  the  following: 

•  Choice  of  visual  display  and  other  presentation  techniques  (e.g.,  pie  charts,  bar 
charts,  histograms,  radar  charts,  line  graphs,  scatter  plots,  or  tables) 

•  Choice  of  appropriate  descriptive  statistics  (e.g.,  arithmetic  mean,  median,  or 
mode) 

•  Decisions  about  statistical  sampling  criteria  when  it  is  impossible  or  unnecessary 
to  examine  every  data  element 

•  Decisions  about  how  to  handle  analysis  in  the  presence  of  missing  data  elements 

•  Selection  of  appropriate  analysis  tools 

Descriptive  statistics  are  typically  used  in  data  analysis  to  do  the  following: 

•  Examine  distributions  on  the  specified  measures  (e.g.,  central  tendency,  extent  of 
variation,  or  data  points  exhibiting  unusual  variation) 

•  Examine  the  interrelationships  among  the  specified  measures  (e.g.,  comparisons 
of  defects  by  phase  of  the  product’s  lifecycle  or  by  product  component) 

•  Display  changes  over  time 

3.  Specify  administrative  procedures  for  analyzing  the  data  and 
communicating  the  results. 
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Issues  to  be  considered  typically  include  the  following: 

•  Identifying  the  persons  and  groups  responsible  for  analyzing  the  data  and 
presenting  the  results 

•  Determining  the  timeline  to  analyze  the  data  and  present  the  results 

•  Determining  the  venues  for  communicating  the  results  (e.g.,  progress  reports, 
transmittal  memos,  written  reports,  or  staff  meetings) 

4.  Review  and  update  the  proposed  content  and  format  of  the 
specified  analyses  and  reports. 

All  of  the  proposed  content  and  format  are  subject  to  review  and  revision, 
including  analytic  methods  and  tools,  administrative  procedures,  and  priorities. 

The  relevant  stakeholders  consulted  should  include  intended  end  users, 
sponsors,  data  analysts,  and  data  providers. 

5.  Update  measures  and  measurement  objectives  as  necessary. 

Just  as  measurement  needs  drive  data  analysis,  clarification  of  analysis  criteria 
can  affect  measurement.  Specifications  for  some  measures  may  be  refined  further 
based  on  the  specifications  established  for  data  analysis  procedures.  Other 
measures  may  prove  to  be  unnecessary,  or  a  need  for  additional  measures  may 
be  recognized. 

The  exercise  of  specifying  how  measures  will  be  analyzed  and  reported  may  also 
suggest  the  need  for  refining  the  measurement  objectives  themselves. 

6.  Specify  criteria  for  evaluating  the  utility  of  the  analysis  results  and 
for  evaluating  the  conduct  of  the  measurement  and  analysis 
activities. 

Criteria  for  evaluating  the  utility  of  the  analysis  might  address  the  extent  to  which 
the  following  apply: 

•  The  results  are  (1)  provided  on  a  timely  basis,  (2)  understandable,  and  (3)  used 
for  decision  making. 

•  The  work  does  not  cost  more  to  perform  than  is  justified  by  the  benefits  that  it 
provides. 

Criteria  for  evaluating  the  conduct  of  the  measurement  and  analysis  might  include 
the  extent  to  which  the  following  apply: 

•  The  amount  of  missing  data  or  the  number  of  flagged  inconsistencies  is  beyond 
specified  thresholds. 

•  There  is  selection  bias  in  sampling  (e.g.,  only  satisfied  end  users  are  surveyed  to 
evaluate  end-user  satisfaction,  or  only  unsuccessful  projects  are  evaluated  to 
determine  overall  productivity). 

•  The  measurement  data  are  repeatable  (e.g.,  statistically  reliable). 

•  Statistical  assumptions  have  been  satisfied  (e.g.,  about  the  distribution  of  data  or 
about  appropriate  measurement  scales). 
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SG  2  Provide  Measurement  Results 

Measurement  results,  which  address  identified  information  needs  and 
objectives,  are  provided. 

The  primary  reason  for  doing  measurement  and  analysis  is  to  address 
identified  information  needs  and  objectives.  Measurement  results  based 
on  objective  evidence  can  help  to  monitor  performance,  fulfill 
contractual  obligations,  make  informed  management  and  technical 
decisions,  and  enable  corrective  actions  to  be  taken. 


SP  2.1  Collect  Measurement  Data 

Obtain  specified  measurement  data. 


The  data  necessary  for  analysis  are  obtained  and  checked  for 
completeness  and  integrity. 

Typical  Work  Products 

1 .  Base  and  derived  measurement  data  sets 

2.  Results  of  data  integrity  tests 

Subpractices 

1 .  Obtain  the  data  for  base  measures. 

Data  are  collected  as  necessary  for  previously  used  as  well  as  for  newly  specified 
base  measures.  Existing  data  are  gathered  from  project  records  or  from 
elsewhere  in  the  organization. 

Note  that  data  that  were  collected  earlier  may  no  longer  be  available  for  reuse  in 
existing  databases,  paper  records,  or  formal  repositories. 

2.  Generate  the  data  for  derived  measures. 

Values  are  newly  calculated  for  all  derived  measures. 

3.  Perform  data  integrity  checks  as  close  to  the  source  of  the  data  as 
possible. 

All  measurements  are  subject  to  error  in  specifying  or  recording  data.  It  is  always 
better  to  identify  such  errors  and  to  identify  sources  of  missing  data  early  in  the 
measurement  and  analysis  cycle. 
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Checks  can  include  scans  for  missing  data,  out-of-bounds  data  values,  and 
unusual  patterns  and  correlation  across  measures.  It  is  particularly  important  to  do 
the  following: 

•  Test  and  correct  for  inconsistency  of  classifications  made  by  human  judgment 
(i.e.,  to  determine  how  frequently  people  make  differing  classification  decisions 
based  on  the  same  information,  otherwise  known  as  “inter-coder  reliability”). 

•  Empirically  examine  the  relationships  among  the  measures  that  are  used  to 
calculate  additional  derived  measures.  Doing  so  can  ensure  that  important 
distinctions  are  not  overlooked  and  that  the  derived  measures  convey  their 
intended  meanings  (otherwise  known  as  “criterion  validity”). 

SP  2.2  Analyze  Measurement  Data 

Analyze  and  interpret  measurement  data. 


The  measurement  data  are  analyzed  as  planned,  additional  analyses 
are  conducted  as  necessary,  results  are  reviewed  with  relevant 
stakeholders,  and  necessary  revisions  for  future  analyses  are  noted. 

Typical  Work  Products 

1 .  Analysis  results  and  draft  reports 

Subpractices 

1 .  Conduct  initial  analyses,  interpret  the  results,  and  draw  preliminary 
conclusions. 

The  results  of  data  analyses  are  rarely  self-evident.  Criteria  for  interpreting  the 
results  and  drawing  conclusions  should  be  stated  explicitly. 

2.  Conduct  additional  measurement  and  analysis  as  necessary,  and 
prepare  results  for  presentation. 

The  results  of  planned  analyses  may  suggest  (or  require)  additional,  unanticipated 
analyses.  In  addition,  they  may  identify  needs  to  refine  existing  measures,  to 
calculate  additional  derived  measures,  or  even  to  collect  data  for  additional  base 
measures  to  properly  complete  the  planned  analysis.  Similarly,  preparing  the 
initial  results  for  presentation  may  identify  the  need  for  additional,  unanticipated 
analyses. 

3.  Review  the  initial  results  with  relevant  stakeholders. 

It  may  be  appropriate  to  review  initial  interpretations  of  the  results  and  the  way  in 
which  they  are  presented  before  disseminating  and  communicating  them  more 
widely. 

Reviewing  the  initial  results  before  their  release  may  prevent  needless 
misunderstandings  and  lead  to  improvements  in  the  data  analysis  and 
presentation. 
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Relevant  stakeholders  with  whom  reviews  may  be  conducted  include  intended 
end  users  and  sponsors,  as  well  as  data  analysts  and  data  providers. 

4.  Refine  criteria  for  future  analyses. 

Valuable  lessons  that  can  improve  future  efforts  are  often  learned  from  conducting 
data  analyses  and  preparing  results.  Similarly,  ways  to  improve  measurement 
specifications  and  data  collection  procedures  may  become  apparent,  as  may 
ideas  for  refining  identified  information  needs  and  objectives. 


SP  2.3  Store  Data  and  Results 

Manage  and  store  measurement  data,  measurement 
specifications,  and  analysis  results. 


Storing  measurement-related  information  enables  the  timely  and  cost- 
effective  future  use  of  historical  data  and  results.  The  information  also  is 
needed  to  provide  sufficient  context  for  interpretation  of  the  data, 
measurement  criteria,  and  analysis  results. 

Information  stored  typically  includes  the  following: 

•  Measurement  plans 

•  Specifications  of  measures 

•  Sets  of  data  that  have  been  collected 

•  Analysis  reports  and  presentations 

The  stored  information  contains  or  references  the  information  needed  to 
understand  and  interpret  the  measures  and  to  assess  them  for 
reasonableness  and  applicability  (e.g.,  measurement  specifications 
used  on  different  projects  when  comparing  across  projects). 

Data  sets  for  derived  measures  typically  can  be  recalculated  and  need 
not  be  stored.  However,  it  may  be  appropriate  to  store  summaries 
based  on  derived  measures  (e.g.,  charts,  tables  of  results,  or  report 
prose). 

Interim  analysis  results  need  not  be  stored  separately  if  they  can  be 
efficiently  reconstructed. 

Projects  may  choose  to  store  project-specific  data  and  results  in  a 
project-specific  repository.  When  data  are  shared  more  widely  across 
projects,  the  data  may  reside  in  the  organization’s  measurement 
repository. 

Refer  to  the  Establish  the  Organization’s  Measurement  Repository 
specific  practice  of  the  Organizational  Process  Definition  process  area 
for  more  information  about  establishing  the  organization’s  measurement 
repository. 
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Refer  to  the  Configuration  Management  process  area  for  information 
about  managing  measurement  work  products. 

Typical  Work  Products 

1 .  Stored  data  inventory 

Subpractices 

1 .  Review  the  data  to  ensure  their  completeness,  integrity,  accuracy, 
and  currency. 

2.  Store  the  data  according  to  the  data  storage  procedures. 

3.  Make  the  stored  contents  available  for  use  only  by  appropriate 
groups  and  personnel. 

4.  Prevent  the  stored  information  from  being  used  inappropriately. 


Examples  of  ways  to  prevent  inappropriate  use  of  the  data  and  related  information 
include  controlling  access  to  data  and  educating  people  on  the  appropriate  use  of 
data. 


Examples  of  inappropriate  use  include  the  following: 

•  Disclosure  of  information  that  was  provided  in  confidence 

•  Faulty  interpretations  based  on  incomplete,  out-of-context,  or  otherwise 
misleading  information 

•  Measures  used  to  improperly  evaluate  the  performance  of  people  or  to  rank 
projects 

•  Impugning  the  integrity  of  specific  individuals 


SP  2.4  Communicate  Results 

Report  results  of  measurement  and  analysis  activities  to  all 
relevant  stakeholders. 


The  results  of  the  measurement  and  analysis  process  are 
communicated  to  relevant  stakeholders  in  a  timely  and  usable  fashion 
to  support  decision  making  and  assist  in  taking  corrective  action. 

Relevant  stakeholders  include  intended  users,  sponsors,  data  analysts, 
and  data  providers. 

Typical  Work  Products 

1 .  Delivered  reports  and  related  analysis  results 

2.  Contextual  information  or  guidance  to  aid  in  the  interpretation  of 
analysis  results 
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Subpractices 

1 .  Keep  relevant  stakeholders  apprised  of  measurement  results  on  a 
timely  basis. 

Measurement  results  are  communicated  in  time  to  be  used  for  their  intended 
purposes.  Reports  are  unlikely  to  be  used  if  they  are  distributed  with  little  effort  to 
follow  up  with  those  who  need  to  know  the  results. 

To  the  extent  possible  and  as  part  of  the  normal  way  they  do  business,  users  of 
measurement  results  are  kept  personally  involved  in  setting  objectives  and 
deciding  on  plans  of  action  for  measurement  and  analysis.  The  users  are  regularly 
kept  apprised  of  progress  and  interim  results. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  the  use  of  measurement  results. 

2.  Assist  relevant  stakeholders  in  understanding  the  results. 

Results  are  reported  in  a  clear  and  concise  manner  appropriate  to  the 
methodological  sophistication  of  the  relevant  stakeholders.  They  are 
understandable,  easily  interpretable,  and  clearly  tied  to  identified  information 
needs  and  objectives. 

The  data  are  often  not  self-evident  to  practitioners  who  are  not  measurement 
experts.  Measurement  choices  should  be  explicitly  clear  about  the  following: 

•  How  and  why  the  base  and  derived  measures  were  specified 

•  How  the  data  were  obtained 

•  How  to  interpret  the  results  based  on  the  data  analysis  methods  that  were  used 

•  How  the  results  address  information  needs 


Examples  of  actions  to  assist  in  understanding  of  results  include  the  following: 

•  Discussing  the  results  with  the  relevant  stakeholders 

•  Providing  a  transmittal  memo  that  provides  background  and  explanation 

•  Briefing  users  on  the  results 

•  Providing  training  on  the  appropriate  use  and  understanding  of  measurement 
results 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  measurement  and  analysis 
process  to  develop  work  products  and  provide  services  to 
achieve  the  specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  measurement  and  analysis  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  aligning 
measurement  objectives  and  activities  with  identified  information  needs 
and  objectives  and  for  providing  measurement  results. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
measurement  and  analysis  process. 


Elaboration: 

This  plan  for  performing  the  measurement  and  analysis  process  can  be 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  measurement 
and  analysis  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 
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Elaboration: 

Measurement  personnel  may  be  employed  full  time  or  part  time.  A 
measurement  group  may  or  may  not  exist  to  support  measurement 
activities  across  multiple  projects. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Statistical  packages 

•  Packages  that  support  data  collection  over  networks 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  measurement  and  analysis  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  measurement 
and  analysis  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 

I  •  Statistical  techniques 

:  •  Data  collection,  analysis,  and  reporting  processes 
•  Development  of  goal-related  measurements  (e.g.,  Goal  Question  Metric) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  measurement  and 
analysis  process  under  appropriate  levels  of  control. 

Elaboration: 

:  Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Specifications  of  base  and  derived  measures 
i  •  Data  collection  and  storage  procedures 
i  •  Base  and  derived  measurement  data  sets 
i  •  Analysis  results  and  draft  reports 
:  •  Data  analysis  tools 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
measurement  and  analysis  process  as  planned. 

Elaboration: 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

:  •  Establishing  measurement  objectives  and  procedures 
:  •  Assessing  measurement  data 

:  •  Providing  meaningful  feedback  to  those  responsible  for  providing  the  raw  data  on 
which  the  analysis  and  results  depend 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  measurement  and  analysis  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Percentage  of  projects  using  progress  and  performance  measures 

•  Percentage  of  measurement  objectives  addressed 

•  Schedule  for  collection  and  review  of  measurement  data 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  measurement  and 
analysis  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance. 

Elaboration: 

:  Examples  of  activities  reviewed  include  the  following: 
j  •  Aligning  measurement  and  analysis  activities 

•  Providing  measurement  results 

Examples  of  work  products  reviewed  include  the  following: 

:  •  Specifications  of  base  and  derived  measures 
i  •  Data  collection  and  storage  procedures 

•  Analysis  results  and  draft  reports 
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GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  measurement 
and  analysis  process  with  higher  level  management  and 
resolve  issues. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 


Continuous/Maturity  Levels  3  -  5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
measurement  and  analysis  process. 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  measurement  and  analysis  process  to  support 
the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Data  currency  status 

•  Results  of  data  integrity  tests 

•  Data  analysis  reports 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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Continuous  Only 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
measurement  and  analysis  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  measurement  and  analysis  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  measurement  and 
analysis  process  in  fulfilling  the  relevant  business  objectives  of 
the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  measurement  and  analysis  process. 
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ORGANIZATIONAL  INNOVATION  AND  DEPLOYMENT 

A  Process  Management  Process  Area  at  Maturity  Level  5 


Purpose 


The  purpose  of  Organizational  Innovation  and  Deployment  (OID)  is  to 
select  and  deploy  incremental  and  innovative  improvements  that 
measurably  improve  the  organization’s  processes  and  technologies. 
The  improvements  support  the  organization’s  quality  and  process- 
performance  objectives  as  derived  from  the  organization’s  business 
objectives. 


Introductory  Notes 


The  Organizational  Innovation  and  Deployment  process  area  enables 
the  selection  and  deployment  of  improvements  that  can  enhance  the 
organization’s  ability  to  meet  its  quality  and  process-performance 
objectives.  (See  the  definition  of  “quality  and  process-performance 
objectives”  in  the  glossary.)  The  term  “improvement,”  as  used  in  this 
process  area,  refers  to  all  of  the  ideas  (proven  and  unproven)  that 
would  change  the  organization’s  processes  and  technologies  to  better 
meet  the  organization’s  quality  and  process-performance  objectives. 

Quality  and  process-performance  objectives  that  this  process  area 
might  address  include  the  following: 

•  Improved  product  quality  (e.g.,  functionality,  performance) 

•  Increased  productivity 

•  Decreased  cycle  time 

•  Greater  customer  and  end-user  satisfaction 

•  Shorter  development  or  production  time  to  change  functionality  or 
add  new  features,  or  adapt  to  new  technologies 

•  Reduce  delivery  time 

•  Reduce  time  to  adapt  to  new  technologies  and  business  needs 

Achievement  of  these  objectives  depends  on  the  successful 
establishment  of  an  infrastructure  that  enables  and  encourages  all 
people  in  the  organization  to  propose  potential  improvements  to  the 
organization’s  processes  and  technologies.  Achievement  of  these 
objectives  also  depends  on  being  able  to  effectively  evaluate  and 
deploy  proposed  improvements  to  the  organization’s  processes  and 
technologies.  All  members  of  the  organization  can  participate  in  the 
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organization’s  process-  and  technology-improvement  activities.  Their 
proposals  are  systematically  gathered  and  addressed. 

Pilots  are  conducted  to  evaluate  significant  changes  involving  untried, 
high-risk,  or  innovative  improvements  before  they  are  broadly  deployed. 

Process  and  technology  improvements  that  will  be  deployed  across  the 
organization  are  selected  from  process-  and  technology-improvement 
proposals  based  on  the  following  criteria: 

•  A  quantitative  understanding  of  the  organization’s  current  quality 
and  process  performance 

•  The  organization’s  quality  and  process-performance  objectives 

•  Estimates  of  the  improvement  in  quality  and  process  performance 
resulting  from  deploying  the  process  and  technology  improvements 

•  Estimated  costs  of  deploying  process  and  technology 
improvements,  and  the  resources  and  funding  available  for  such 
deployment 

The  expected  benefits  added  by  the  process  and  technology 
improvements  are  weighed  against  the  cost  and  impact  to  the 
organization.  Change  and  stability  must  be  balanced  carefully.  Change 
that  is  too  great  or  too  rapid  can  overwhelm  the  organization,  destroying 
its  investment  in  organizational  learning  represented  by  organizational 
process  assets.  Rigid  stability  can  result  in  stagnation,  allowing  the 
changing  business  environment  to  erode  the  organization’s  business 
position. 

Improvements  are  deployed,  as  appropriate,  to  new  and  ongoing 
projects. 

In  this  process  area,  the  term  “process  and  technology  improvements” 
refers  to  incremental  and  innovative  improvements  to  processes  and 
also  to  process  or  product  technologies  (including  project  work 
environments). 

The  informative  material  in  this  process  area  is  written  with  the 
assumption  that  the  specific  practices  are  applied  to  a  quantitatively 
managed  process.  The  specific  practices  of  this  process  area  may  be 
applicable,  but  with  reduced  value,  if  the  assumption  is  not  met. 

The  specific  practices  in  this  process  area  complement  and  extend 
those  found  in  the  Organizational  Process  Focus  process  area.  The 
focus  of  this  process  area  is  process  improvement  that  is  based  on  a 
quantitative  knowledge  of  the  organization’s  set  of  standard  processes 
and  technologies  and  their  expected  quality  and  performance  in 
predictable  situations.  In  the  Organizational  Process  Focus  process 
area,  no  assumptions  are  made  about  the  quantitative  basis  of 
improvement. 
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Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  incorporating  the  deployed  process  improvements 
into  organizational  process  assets. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  soliciting,  collecting,  and  handling  process 
improvement  proposals  and  coordinating  the  deployment  of  process 
improvement  into  the  project’s  defined  processes. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  providing  updated  training  to  support  deployment  of  process  and 
technology  improvements. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  quality  and  process-performance  objectives  and 
process-performance  models.  Quality  and  process-performance 
objectives  are  used  to  analyze  and  select  process-  and  technology- 
improvement  proposals  for  deployment.  Process-performance  models 
are  used  to  quantify  the  impact  and  benefits  of  innovations. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  coordinating  the  deployment  of  process  and 
technology  improvements  into  the  project’s  defined  process  and  project 
work  environment. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluations  related  to  improvement  proposals 
and  innovations. 

Specific  Goal  and  Practice  Summary 

SG  1  Select  Improvements 

SP  1 .1  Collect  and  Analyze  Improvement  Proposals 

SP  1 .2  Identify  and  Analyze  Innovations 
SP1.3  Pilot  Improvements 
SP  1 .4  Select  Improvements  for  Deployment 

SG  2  Deploy  Improvements 

SP  2.1  Plan  the  Deployment 

SP  2.2  Manage  the  Deployment 

SP  2.3  Measure  Improvement  Effects 
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Specific  Practices  by  Goal 


SG  1  Select  Improvements 

Process  and  technology  improvements,  which  contribute  to  meeting 
quality  and  process-performance  objectives,  are  selected. 


SP  1.1  Collect  and  Analyze  Improvement  Proposals 

Collect  and  analyze  process-  and  technology-improvement 
proposals. 


Each  process-  and  technology-improvement  proposal  must  be 
analyzed. 

Simple  process  and  technology  improvements,  with  well-understood 
benefits  and  effects,  will  not  usually  undergo  detailed  evaluations. 


:  Examples  of  simple  process  and  technology  improvements  include  the  following: 

;  •  Add  an  item  to  a  peer  review  checklist. 

:  •  Combine  the  technical  review  and  management  review  for  suppliers  into  a  single 
technical/management  review. 


Typical  Work  Products 

1.  Analyzed  process-  and  technology-improvement  proposals 
Subpractices 

1 .  Collect  process-  and  technology-improvement  proposals. 

A  process-  and  technology-improvement  proposal  documents  proposed 
incremental  and  innovative  improvements  to  specific  processes  and  technologies. 
Managers  and  staff  in  the  organization,  as  well  as  customers,  end  users,  and 
suppliers  can  submit  process-  and  technology-improvement  proposals.  Process 
and  technology  improvements  may  be  implemented  at  the  local  level  before  being 
proposed  for  the  organization. 
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Examples  of  sources  for  process-  and  technology-improvement  proposals  include 

the  following:  j 

•  Findings  and  recommendations  from  process  appraisals  j 

•  The  organization’s  quality  and  process-performance  objectives 

•  Analysis  of  data  about  customer  and  end-user  problems  as  well  as  customer  and  i 

end-user  satisfaction 

•  Analysis  of  data  about  project  performance  compared  to  quality  and  productivity  j 

objectives 

•  Analysis  of  technical  performance  measures 

•  Results  of  process  and  product  benchmarking  efforts  : 

•  Analysis  of  data  on  defect  causes  j 

•  Measured  effectiveness  of  process  activities  j 

•  Measured  effectiveness  of  project  work  environments  j 

•  Examples  of  process-  and  technology-improvement  proposals  that  were  : 

successfully  adopted  elsewhere 

•  Feedback  on  previously  submitted  process-  and  technology-improvement 

proposals  j 

•  Spontaneous  ideas  from  managers  and  staff 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  process-  and  technology-improvement 
proposals. 

2.  Analyze  the  costs  and  benefits  of  process-  and  technology- 
improvement  proposals  as  appropriate. 

Process-  and  technology-improvement  proposals  that  have  a  large  cost-to-benefit 
ratio  are  rejected. 

Criteria  for  evaluating  costs  and  benefits  include  the  following: 

•  Contribution  toward  meeting  the  organization’s  quality  and  process-performance 
objectives 

•  Effect  on  mitigating  identified  project  and  organizational  risks 

•  Ability  to  respond  quickly  to  changes  in  project  requirements,  market  situations, 
and  the  business  environment 

•  Effect  on  related  processes  and  associated  assets 

•  Cost  of  defining  and  collecting  data  that  supports  the  measurement  and  analysis 
of  the  process-  and  technology-improvement  proposal 

•  Expected  life  span  of  the  proposal 

Process-  and  technology-improvement  proposals  that  would  not  improve  the 
organization's  processes  are  rejected. 
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Process-performance  models  provide  insight  into  the  effect  of  process  changes 
on  process  capability  and  performance. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process-performance  models. 

3.  Identify  the  process-  and  technology-improvement  proposals  that 
are  innovative. 

Innovative  improvements  are  also  identified  and  analyzed  in  the  Identify  and 
Analyze  Innovations  specific  practice. 

Whereas  this  specific  practice  analyzes  proposals  that  have  been  passively 
collected,  the  purpose  of  the  Identify  and  Analyze  innovations  specific  practice  is 
to  actively  search  for  and  locate  innovative  improvements.  The  search  primarily 
involves  looking  outside  the  organization. 

Innovative  improvements  are  typically  identified  by  reviewing  process-  and 
technology-improvement  proposals  or  by  actively  investigating  and  monitoring 
innovations  that  are  in  use  in  other  organizations  or  are  documented  in  research 
literature.  Innovation  may  be  inspired  by  internal  improvement  objectives  or  by  the 
external  business  environment. 

Innovative  improvements  are  typically  major  changes  to  the  process  that 
represent  a  break  from  the  old  way  of  doing  things  (e.g.,  changing  the  lifecycle 
model).  Innovative  improvements  may  also  include  changes  in  the  products  that 
support,  enhance,  or  automate  the  process  (e.g.,  using  off-the-shelf  products  to 
support  the  process). 


Examples  of  innovative  improvements  include  the  following: 

•  Advances  in  computer  and  related  hardware  products 

•  New  support  tools 

•  New  techniques,  methodologies,  processes,  or  lifecycle  models 

•  New  interface  standards 

•  New  reusable  components 

•  New  management  techniques 

•  New  quality-improvement  techniques 

•  New  process  development  and  deployment  support  tools 


4.  Identify  potential  barriers  and  risks  to  deploying  each  process-  and 
technology-improvement  proposal. 
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Examples  of  barriers  to  deploying  process  and  technology  improvements  include 
the  following: 

•  Turf  guarding  and  parochial  perspectives 

•  Unclear  or  weak  business  rationale 

•  Lack  of  short-term  benefits  and  visible  successes 

•  Unclear  picture  of  what  is  expected  from  everyone 

•  Too  many  changes  at  the  same  time 

•  _  Lack  of  involvement  and  support  of  relevant  stakeholders 


Examples  of  risk  factors  that  affect  the  deployment  of  process  and  technology 

improvements  include  the  following: 

•  Compatibility  of  the  improvement  with  existing  processes,  values,  and  skills  of 
potential  end  users 

•  Complexity  of  the  improvement 

•  Difficulty  implementing  the  improvement 

•  Ability  to  demonstrate  the  value  of  the  improvement  before  widespread 
deployment 

•  Justification  for  large,  up-front  investments  in  areas  such  as  tools  and  training 

•  Inability  to  overcome  “technology  drag”  where  the  current  implementation  is  used 
successfully  by  a  large  and  mature  installed  base  of  end  users 


5.  Estimate  the  cost,  effort,  and  schedule  required  for  deploying  each 
process-  and  technology-improvement  proposal. 

6.  Select  the  process-  and  technology-improvement  proposals  to  be 
piloted  before  broadscale  deployment. 

Since  innovations,  by  definition,  usually  represent  a  major  change,  most 
innovative  improvements  will  be  piloted. 

7.  Document  the  results  of  the  evaluation  of  each  process-  and 
technology-improvement  proposal. 

8.  Monitor  the  status  of  each  process-  and  technology-improvement 
proposal. 


SP  1.2  Identify  and  Analyze  Innovations 

Identify  and  analyze  innovative  improvements  that  could 
increase  the  organization’s  quality  and  process  performance. 


The  specific  practice,  Collect  and  Analyze  Improvement  Proposals, 
analyzes  proposals  that  are  passively  collected.  The  purpose  of  this 
specific  practice  is  to  actively  search  for,  locate,  and  analyze  innovative 
improvements.  This  search  primarily  involves  looking  outside  the 
organization. 
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Typical  Work  Products 

1.  Candidate  innovative  improvements 

2.  Analysis  of  proposed  innovative  improvements 
Subpractices 

1 .  Analyze  the  organization's  set  of  standard  processes  to  determine 
areas  where  innovative  improvements  would  be  most  helpful. 

These  analyses  are  performed  to  determine  which  subprocesses  are  critical  to 
achieving  the  organization’s  quality  and  process-performance  objectives  and 
which  ones  are  good  candidates  to  be  improved. 

2.  Investigate  innovative  improvements  that  may  improve  the 
organization's  set  of  standard  processes. 

Investigating  innovative  improvements  involves  the  following: 

•  Systematically  maintaining  awareness  of  leading  relevant  technical  work  and 
technology  trends 

•  Periodically  searching  for  commercially  available  innovative  improvements 

•  Collecting  proposals  for  innovative  improvements  from  the  projects  and  the 
organization 

•  Systematically  reviewing  processes  and  technologies  used  externally  and 
comparing  them  to  those  used  within  the  organization 

•  Identifying  areas  where  innovative  improvements  have  been  used  successfully, 
and  reviewing  data  and  documentation  of  experience  using  these  improvements 

•  Identifying  improvements  that  integrate  new  technology  into  products  and  project 
work  environments 

3.  Analyze  potential  innovative  improvements  to  understand  their 
effects  on  process  elements  and  predict  their  influence  on  the 
process. 

Process-performance  models  can  provide  a  basis  for  analyzing  possible  effects  of 
changes  to  process  elements. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process-performance  models. 

4.  Analyze  the  costs  and  benefits  of  potential  innovative 
improvements. 

Innovative  improvements  that  have  a  very  large  cost-to-benefit  ratio  are  rejected. 

5.  Create  process-  and  technology-improvement  proposals  for  those 
innovative  improvements  that  would  result  in  improving  the 
organization's  processes  or  technologies. 
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6.  Select  the  innovative  improvements  to  be  piloted  before  broadscale 
deployment. 

Since  innovations,  by  definition,  usually  represent  a  major  change,  most 
innovative  improvements  will  be  piloted. 

7.  Document  the  results  of  the  evaluations  of  innovative 
improvements. 


SP  1.3  Pilot  Improvements 

Pilot  process  and  technology  improvements  to  select  which 
ones  to  implement. 


Pilots  are  performed  to  assess  new  and  unproven  major  changes 
before  they  are  broadly  deployed,  as  appropriate. 

The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Implement  the  Action  Proposals  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects). 

Typical  Work  Products 

1 .  Pilot  evaluation  reports 

2.  Documented  lessons  learned  from  pilots 

Subpractices 

1.  Plan  the  pilots. 

When  planning  pilots,  it  is  critical  to  define  quantitative  criteria  to  be  used  for 
evaluating  pilot  results. 

2.  Review  and  get  relevant  stakeholder  agreement  on  the  plans  for 
the  pilots. 

3.  Consult  with  and  assist  the  people  performing  the  pilots. 

4.  Perform  each  pilot  in  an  environment  that  is  characteristic  of  the 
environment  present  in  a  broadscale  deployment. 

5.  Track  the  pilots  against  their  plans. 

6.  Review  and  document  the  results  of  pilots. 
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Pilot  results  are  evaluated  using  the  quantitative  criteria  defined  during  pilot 
planning.  Reviewing  and  documenting  the  results  of  pilots  usually  involves  the 
following: 

•  Deciding  whether  to  terminate  the  pilot,  replan  and  continue  the  pilot,  or  proceed 
with  deploying  the  process  and  technology  improvement 

•  Updating  the  disposition  of  process-  and  technology-improvement  proposals 
associated  with  the  pilot 

•  Identifying  and  documenting  new  process-  and  technology-improvement 
proposals  as  appropriate 

•  Identifying  and  documenting  lessons  learned  and  problems  encountered  during 
the  pilot 

SP  1.4  Select  Improvements  for  Deployment 

Select  process  and  technology  improvements  for  deployment 
across  the  organization. 


Selection  of  process  and  technology  improvements  for  deployment 
across  the  organization  is  based  on  quantifiable  criteria  derived  from 
the  organization’s  quality  and  process-performance  objectives. 

Typical  Work  Products 

1 .  Process  and  technology  improvements  selected  for  deployment 
Subpractices 

1 .  Prioritize  the  candidate  process  and  technology  improvements  for 
deployment. 

Priority  is  based  on  an  evaluation  of  the  estimated  cost-to-benefit  ratio  with  regard 
to  the  quality  and  process-performance  objectives. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  quality  and  process-performance 
objectives. 

2.  Select  the  process  and  technology  improvements  to  be  deployed. 

The  selection  of  the  process  improvements  is  based  on  their  priorities  and  the 
available  resources. 

3.  Determine  how  each  process  and  technology  improvement  will  be 
deployed. 


Organizational  Innovation  and  Deployment  (OID) 


207 


CMMI  for  Development 
Version  1.2 

I  Examples  of  where  the  process  and  technology  improvements  may  be  deployed 
:  include  the  following: 

|  •  Organizational  process  assets 
:  •  Project-specific  or  common  work  environments 
i  •  Organization's  product  families 
j  •  Organization's  capabilities 
j  •  Organization’s  projects 

•  Organizational  groups 

4.  Document  the  results  of  the  selection  process. 

The  results  of  the  selection  process  usually  include  the  following: 

•  The  selection  criteria  for  candidate  improvements 

•  The  disposition  of  each  improvement  proposal 

•  The  rationale  for  the  disposition  of  each  improvement  proposal 

•  The  assets  to  be  changed  for  each  selected  improvement 

SG  2  Deploy  Improvements 

Measurable  improvements  to  the  organization's  processes  and 
technologies  are  continually  and  systematically  deployed. 


SP  2.1  Plan  the  Deployment 

Establish  and  maintain  the  plans  for  deploying  the  selected 
process  and  technology  improvements. 


The  plans  for  deploying  each  process  and  technology  improvement 
may  be  included  in  the  organization’s  plan  for  organizational  innovation 
and  deployment  or  they  may  be  documented  separately. 

The  implementation  of  this  specific  practice  complements  the  Deploy 
Organizational  Process  Assets  specific  practice  in  the  Organizational 
Process  Focus  process  area,  and  adds  the  use  of  quantitative  data  to 
guide  the  deployment  and  to  determine  the  value  of  the  improvements 
with  respect  to  quality  and  process-performance  objectives. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets. 

This  specific  practice  plans  the  deployment  of  individual  process  and 
technology  improvements.  The  Plan  the  Process  generic  practice 
addresses  comprehensive  planning  that  covers  the  specific  practices  in 
this  process  area. 
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Typical  Work  Products 

1 .  Deployment  plan  for  selected  process  and  technology 
improvements 

Subpractices 

1 .  Determine  how  each  process  and  technology  improvement  must 
be  adjusted  for  organization-wide  deployment. 

Process  and  technology  improvements  proposed  within  a  limited  context  (e.g.,  for 
a  single  project)  might  have  to  be  modified  to  work  across  the  organization. 

2.  Determine  the  changes  necessary  to  deploy  each  process  and 
technology  improvement. 

:  Examples  of  changes  needed  to  deploy  a  process  and  technology  improvement 
j  include  the  following: 

:  •  Process  descriptions,  standards,  and  procedures 
i  •  Work  environments 
i  •  Education  and  training 
|  •  Skills 

:  •  Existing  commitments 
;  •  Existing  activities 
|  •  Continuing  support  to  end  users 
•  Organizational  culture  and  characteristics 

3.  Identify  strategies  to  address  potential  barriers  to  deploying  each 
process  and  technology  improvement. 

4.  Establish  measures  and  objectives  for  determining  the  value  of 
each  process  and  technology  improvement  with  respect  to  the 
organization’s  quality  and  process-performance  objectives. 


Examples  of  measures  for  determining  the  value  of  a  process  and  technology 
improvement  include  the  following: 

•  Return  on  investment 

•  Time  to  recover  the  cost  of  the  process  or  technology  improvement 

•  Measured  improvement  in  the  project’s  or  organization’s  process  performance 

•  Number  and  types  of  project  and  organizational  risks  mitigated  by  the  process  or 
technology  improvement 

•  Average  time  required  to  respond  to  changes  in  project  requirements,  market 
situations,  and  the  business  environment 
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Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

5.  Document  the  plan  for  deploying  each  process  and  technology 
improvement. 

6.  Review  and  get  agreement  with  relevant  stakeholders  on  the  plan 
for  deploying  each  process  and  technology  improvement. 

7.  Revise  the  plan  for  deploying  each  process  and  technology 
improvement  as  necessary. 


SP  2.2  Manage  the  Deployment 

Manage  the  deployment  of  the  selected  process  and 
technology  improvements. 


The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Implement  the  Action  Proposals  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects).  The  primary  difference  is  that  in  the  Causal  Analysis 
and  Resolution  process  area,  planning  is  done  to  manage  the  removal 
of  the  root  causes  of  defects  or  problems  from  the  project’s  defined 
processes.  In  the  Organizational  Innovation  and  Deployment  process 
area,  planning  is  done  to  manage  the  deployment  of  improvements  to 
the  organization’s  processes  and  technologies  that  can  be  quantified 
against  the  organization’s  business  objectives. 

Typical  Work  Products 

1 .  Updated  training  materials  (to  reflect  deployed  process  and 
technology  improvements) 

2.  Documented  results  of  process-  and  technology-improvement 
deployment  activities 

3.  Revised  process-  and  technology-improvement  measures, 
objectives,  priorities,  and  deployment  plans 

Subpractices 

1 .  Monitor  the  deployment  of  the  process  and  technology 
improvements  using  the  deployment  plan. 

2.  Coordinate  the  deployment  of  process  and  technology 
improvements  across  the  organization. 
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Coordinating  deployment  includes  the  following  activities: 

•  Coordinating  the  activities  of  projects,  support  groups,  and  organizational  groups 
for  each  process  and  technology  improvement 

•  Coordinating  the  activities  for  deploying  related  process  and  technology 
improvements 

3.  Quickly  deploy  process  and  technology  improvements  in  a 
controlled  and  disciplined  manner,  as  appropriate. 


Examples  of  methods  for  quickly  deploying  process  and  technology  improvements 

include  the  following: 

•  Using  red-lines,  process  change  notices,  or  other  controlled  process 
documentation  as  interim  process  descriptions 

•  Deploying  process  and  technology  improvements  incrementally,  rather  than  as  a 
single  deployment 

•  Providing  comprehensive  consulting  to  early  adopters  of  the  process  and 
technology  improvement  in  lieu  of  revised  formal  training 


4.  Incorporate  the  process  and  technology  improvements  into 
organizational  process  assets,  as  appropriate. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  organizational  process  assets. 

5.  Coordinate  the  deployment  of  the  process  and  technology 
improvements  into  the  projects'  defined  processes  as  appropriate. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets. 

6.  Provide  consulting,  as  appropriate,  to  support  deployment  of  the 
process  and  technology  improvements. 

7.  Provide  updated  training  materials  to  reflect  the  improvements  to 
the  organizational  process  assets. 

Refer  to  the  Organizational  Training  process  area  for  more 
information  about  training  materials. 

8.  Confirm  that  the  deployment  of  all  process  and  technology 
improvements  is  completed. 

9.  Determine  whether  the  ability  of  the  defined  process  to  meet 
quality  and  process-performance  objectives  is  adversely  affected 
by  the  process  and  technology  improvement,  and  take  corrective 
action  as  necessary. 
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Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  quantitatively  managing  the  project’s 
defined  process  to  achieve  the  project’s  established  quality  and 
process-performance  objectives. 

10.  Document  and  review  the  results  of  process-  and  technology- 
improvement  deployment. 

Documenting  and  reviewing  the  results  includes  the  following: 

•  Identifying  and  documenting  lessons  learned 

•  Identifying  and  documenting  new  process-  and  technology-improvement 
proposals 

•  Revising  process-  and  technology-improvement  measures,  objectives,  priorities, 
and  deployment  plans 

SP  2.3  Measure  Improvement  Effects 

Measure  the  effects  of  the  deployed  process  and  technology 
improvements. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Evaluate  the  Effect  of  Changes  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects). 

Typical  Work  Products 

1 .  Documented  measures  of  the  effects  resulting  from  the  deployed 
process  and  technology  improvements 

Subpractices 

1 .  Measure  the  actual  cost,  effort,  and  schedule  for  deploying  each 
process  and  technology  improvement. 

2.  Measure  the  value  of  each  process  and  technology  improvement. 

3.  Measure  the  progress  toward  achieving  the  organization's  quality 
and  process-performance  objectives. 

4.  Analyze  the  progress  toward  achieving  the  organization's  quality 
and  process-performance  objectives  and  take  corrective  action  as 
needed. 
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Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process-performance  analyses. 

5.  Store  the  measures  in  the  organization’s  measurement  repository. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1 

Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  organizational  innovation 
and  deployment  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  organizational  innovation  and  deployment 
process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  identifying  and 
deploying  process  and  technology  improvements  that  contribute  to 
meeting  quality  and  process-performance  objectives. 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
organizational  innovation  and  deployment  process. 


Elaboration: 

This  plan  for  performing  the  organizational  innovation  and  deployment 
process  differs  from  the  deployment  plans  described  in  a  specific 
practice  in  this  process  area.  The  plan  called  for  in  this  generic  practice 
would  address  the  comprehensive  planning  for  all  of  the  specific 
practices  in  this  process  area,  from  collecting  and  analyzing 
improvement  proposals  all  the  way  through  to  the  measurement  of 
improvement  effects.  In  contrast,  the  deployment  plans  called  for  in  the 
specific  practice  would  address  the  planning  needed  for  the  deployment 
of  individual  process  and  technology  improvements. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
innovation  and  deployment  process,  developing  the  work 
products,  and  providing  the  services  of  the  process. 

Elaboration: 

;  Examples  of  resources  provided  include  the  following  tools: 

;  •  Simulation  packages 

I  •  Prototyping  tools 

I  •  Statistical  packages 

:  •  Dynamic  systems  modeling 

i  •  Subscriptions  to  online  technology  databases  and  publications 

•  Process  modeling  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  organizational  innovation  and  deployment  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
innovation  and  deployment  process  as  needed. 
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Elaboration: 

Examples  of  training  topics  include  the  following: 

I  •  Planning,  designing,  and  conducting  pilots 

I  •  Cost/benefit  analysis 

|  •  Technology  transition 

•  Change  management 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational 
innovation  and  deployment  process  under  appropriate  levels  of 
control. 


Elaboration: 


Examples  of  work  products  placed  under  control  include  the  following: 

•  Documented  lessons  learned  from  pilots 

•  Revised  process-  and  technology-improvement  measures,  objectives,  priorities, 
and  deployment  plans 

•  Updated  training  material 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
organizational  innovation  and  deployment  process  as  planned. 


Elaboration: 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Reviewing  process-  and  technology-improvement  proposals  that  may  have  major 
impacts  on  process  performance  or  on  customer  and  end-user  satisfaction 

•  Providing  feedback  to  the  organization  on  the  status  and  results  of  the  process- 
and  technology-improvement  deployment  activities 


The  feedback  typically  involves: 

•  Informing  the  people  who  submit  process-  and  technology- 
improvement  proposals  about  the  disposition  of  their  proposals 

•  Regularly  informing  relevant  stakeholders  about  the  plans  and 
status  for  selecting  and  deploying  process  and  technology 
improvements 

•  Preparing  and  distributing  a  summary  of  process-  and  technology- 
improvement  selection  and  deployment  activities 
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GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  innovation  and 
deployment  process  against  the  plan  for  performing  the 
process  and  take  appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Change  in  quality 

•  Change  in  process  performance 

•  Schedule  for  activities  to  deploy  a  selected  improvement 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  innovation 
and  deployment  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

|  •  Selecting  improvements 

! 

:  •  Deploying  improvements 

:  Examples  of  work  products  reviewed  include  the  following: 

;  •  Deployment  plans 

|  •  Revised  process-  and  technology-improvement  measures,  objectives,  priorities, 
j  and  deployment  plans 

•  Updated  training  material 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
innovation  and  deployment  process  with  higher  level 
management  and  resolve  issues. 
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Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
organizational  innovation  and  deployment  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  organizational  innovation  and  deployment 
process  to  support  the  future  use  and  improvement  of  the 
organization’s  processes  and  process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 

information  include  the  following: 

•  Lessons  learned  captured  from  relevant  stakeholders  that  identify  barriers  to 
deployment  from  previous  technology  insertions 

•  Documented  measures  of  the  costs  and  benefits  resulting  from  deploying 
innovations 

•  Report  of  a  comparison  of  similar  development  processes  to  identify  the  potential 
for  improving  efficiency 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  innovation  and  deployment  process,  which 
address  quality  and  process  performance,  based  on  customer 
needs  and  business  objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  innovation  and 
deployment  process  to  achieve  the  established  quantitative 
quality  and  process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational 
innovation  and  deployment  process  in  fulfilling  the  relevant 
business  objectives  of  the  organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  organizational  innovation  and  deployment 
process. 
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ORGANIZATIONAL  PROCESS  DEFINITION  +IPPD 

A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Process  Definition  (OPD)  is  to  establish 
and  maintain  a  usable  set  of  organizational  process  assets  and  work 
environment  standards. 


IPPD  Addition 

For  IPPD,  Organizational  Process  Definition  +IPPD  also  covers  the 
establishment  of  organizational  rules  and  guidelines  that  enable 
conducting  work  using  integrated  teams. 


Introductory  Notes 


Organizational  process  assets  enable  consistent  process  performance 
across  the  organization  and  provide  a  basis  for  cumulative,  long-term 
benefits  to  the  organization.  (See  the  definition  of  “organizational 
process  assets”  in  the  glossary.) 

The  organization’s  process  asset  library  is  a  collection  of  items 
maintained  by  the  organization  for  use  by  the  people  and  projects  of  the 
organization.  This  collection  of  items  includes  descriptions  of  processes 
and  process  elements,  descriptions  of  lifecycle  models,  process 
tailoring  guidelines,  process-related  documentation,  and  data.  The 
organization’s  process  asset  library  supports  organizational  learning 
and  process  improvement  by  allowing  the  sharing  of  best  practices  and 
lessons  learned  across  the  organization. 

The  organization’s  set  of  standard  processes  is  tailored  by  projects  to 
create  their  defined  processes.  The  other  organizational  process  assets 
are  used  to  support  tailoring  as  well  as  the  implementation  of  the 
defined  processes.  The  work  environment  standards  are  used  to  guide 
creation  of  project  work  environments. 

A  standard  process  is  composed  of  other  processes  (i.e., 
subprocesses)  or  process  elements.  A  process  element  is  the 
fundamental  (e.g.,  atomic)  unit  of  process  definition  and  describes  the 
activities  and  tasks  to  consistently  perform  work.  Process  architecture 
provides  rules  for  connecting  the  process  elements  of  a  standard 
process.  The  organization’s  set  of  standard  processes  may  include 
multiple  process  architectures. 
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(See  the  definitions  of  “standard  process,”  “process  architecture,” 
“subprocess,”  and  “process  element”  in  the  glossary.) 


The  organizational  process  assets  may  be  organized  in  many  ways,  depending  on  the 
implementation  of  the  Organizational  Process  Definition  process  area.  Examples 
include  the  following: 

•  Descriptions  of  lifecycle  models  may  be  documented  as  part  of  the  organization’s 
set  of  standard  processes,  or  they  may  be  documented  separately. 

•  The  organization’s  set  of  standard  processes  may  be  stored  in  the  organization’s 
process  asset  library,  or  they  may  be  stored  separately. 

•  A  single  repository  may  contain  both  the  measurements  and  the  process-related 
documentation,  or  they  may  be  stored  separately. 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process-related  matters. 


Specific  Goal  and  Practice  Summary 


SG  1  Establish  Organizational  Process  Assets 
SP1.1  Establish  Standard  Processes 

SP  1 .2  Establish  Lifecycle  Model  Descriptions 

SP  1 .3  Establish  Tailoring  Criteria  and  Guidelines 

SP  1 .4  Establish  the  Organization’s  Measurement  Repository 

SP  1 .5  Establish  the  Organization’s  Process  Asset  Library 

SP  1 .6  Establish  Work  Environment  Standards 


IPPD  Addition 

SG  2  Enable  IPPD  Management 

SP  2.1 

Establish  Empowerment  Mechanisms 

SP  2.2 

Establish  Rules  and  Guidelines  for  Integrated  Teams 

SP  2.3 

Balance  Team  and  Home  Organization  Responsibilities 

Specific  Practices  by  Goal 


SG  1  Establish  Organizational  Process  Assets 

A  set  of  organizational  process  assets  is  established  and  maintained. 


220 


Organizational  Process  Definition  +IPPD  (OPD+IPPD) 


CMMI  for  Development 
Version  1.2 


IPPD  Addition 

Integrated  processes  that  emphasize  parallel  rather  than  serial 
development  are  a  cornerstone  of  IPPD  implementation.  The  processes  for 
developing  the  product  and  for  developing  product-related  lifecycle 
processes,  such  as  the  manufacturing  process  and  the  support  process, 
are  integrated  and  conducted  concurrently.  Such  integrated  processes 
should  accommodate  the  information  provided  by  stakeholders 
representing  all  phases  of  the  product  lifecycle  from  both  business  and 
technical  functions.  Processes  for  effective  teamwork  are  also  needed. 


SP  1.1  Establish  Standard  Processes 

Establish  and  maintain  the  organization's  set  of  standard 
processes. 


Standard  processes  may  be  defined  at  multiple  levels  in  an  enterprise 
and  they  may  be  related  in  a  hierarchical  manner.  For  example,  an 
enterprise  may  have  a  set  of  standard  processes  that  is  tailored  by 
individual  organizations  (e.g.,  a  division  or  site)  in  the  enterprise  to 
establish  their  set  of  standard  processes.  The  set  of  standard 
processes  may  also  be  tailored  for  each  of  the  organization’s  business 
areas  or  product  lines.  Thus  “the  organization’s  set  of  standard 
processes”  can  refer  to  the  standard  processes  established  at  the 
organization  level  and  standard  processes  that  may  be  established  at 
lower  levels,  although  some  organizations  may  only  have  a  single  level 
of  standard  processes.  (See  the  definitions  of  “standard  process”  and 
“organization’s  set  of  standard  processes”  in  the  glossary.) 

Multiple  standard  processes  may  be  needed  to  address  the  needs  of 
different  application  domains,  lifecycle  models,  methodologies,  and 
tools.  The  organization’s  set  of  standard  processes  contains  process 
elements  (e.g.,  a  work  product  size-estimating  element)  that  may  be 
interconnected  according  to  one  or  more  process  architectures  that 
describe  the  relationships  among  these  process  elements. 

The  organization’s  set  of  standard  processes  typically  includes 
technical,  management,  administrative,  support,  and  organizational 
processes. 


IPPD  Addition 

In  an  IPPD  environment,  the  organization's  set  of  standard  processes 
includes  a  process  that  projects  use  to  establish  a  shared  vision. 


The  organization’s  set  of  standard  processes  should  collectively  cover 
all  processes  needed  by  the  organization  and  projects,  including  those 
processes  addressed  by  the  process  areas  at  Maturity  Level  2. 
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Typical  Work  Products 

1 .  Organization's  set  of  standard  processes 


Subpractices 

1.  Decompose  each  standard  process  into  constituent  process 
elements  to  the  detail  needed  to  understand  and  describe  the 
process. 

Each  process  element  covers  a  bounded  and  closely  related  set  of  activities.  The 
descriptions  of  the  process  elements  may  be  templates  to  be  filled  in,  fragments 
to  be  completed,  abstractions  to  be  refined,  or  complete  descriptions  to  be  tailored 
or  used  unmodified.  These  elements  are  described  in  sufficient  detail  such  that 
the  process,  when  fully  defined,  can  be  consistently  performed  by  appropriately 
trained  and  skilled  people. 


Examples  of  process  elements  include  the  following: 

•  Template  for  generating  work  product  size  estimates 

•  Description  of  work  product  design  methodology 

•  Tailorable  peer  review  methodology 

•  Template  for  conduct  of  management  reviews 

Specify  the  critical  attributes  of  each  process  element. 

Examples  of  critical  attributes  include  the  following: 

|  • 

Process  roles 

!  • 

Applicable  standards 

• 

Applicable  procedures,  methods,  tools,  and  resources 

• 

Process-performance  objectives 

i  • 

Entry  criteria 

!  • 

Inputs 

• 

Product  and  process  measures  to  be  collected  and  used 

;  • 

Verification  points  (e.g.,  peer  reviews) 

'  • 

Outputs 

• 

Interfaces 

Exit  criteria 

3.  Specify  the  relationships  of  the  process  elements. 
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Examples  of  relationships  include  the  following: 

•  Ordering  of  the  process  elements 

•  Interfaces  among  the  process  elements 

•  Interfaces  with  external  processes 

•  Interdependencies  among  the  process  elements 


The  rules  for  describing  the  relationships  among  process  elements  are  referred  to 
as  “process  architecture."  The  process  architecture  covers  the  essential 
requirements  and  guidelines.  The  detailed  specifications  of  these  relationships  are 
covered  in  the  descriptions  of  the  defined  processes  that  are  tailored  from  the 
organization’s  set  of  standard  processes. 

4.  Ensure  that  the  organization's  set  of  standard  processes  adheres 
to  applicable  policies,  standards,  and  models. 

Adherence  to  applicable  process  standards  and  models  is  typically  demonstrated 
by  developing  a  mapping  from  the  organization’s  set  of  standard  processes  to  the 
relevant  process  standards  and  models.  In  addition,  this  mapping  will  be  a  useful 
input  to  future  appraisals. 

5.  Ensure  that  the  organization’s  set  of  standard  processes  satisfies 
the  process  needs  and  objectives  of  the  organization. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  establishing  and  maintaining  the  organization’s 
process  needs  and  objectives. 

6.  Ensure  that  there  is  appropriate  integration  among  the  processes 
that  are  included  in  the  organization’s  set  of  standard  processes. 

7.  Document  the  organization's  set  of  standard  processes. 

8.  Conduct  peer  reviews  on  the  organization's  set  of  standard 
processes. 

Refer  to  the  Verification  process  area  for  more  information  about 
peer  review. 

9.  Revise  the  organization's  set  of  standard  processes  as  necessary. 

SP  1.2  Establish  Lifecycle  Model  Descriptions 

Establish  and  maintain  descriptions  of  the  lifecycle  models 
approved  for  use  in  the  organization. 


Lifecycle  models  may  be  developed  for  a  variety  of  customers  or  in  a 
variety  of  situations,  since  one  lifecycle  model  may  not  be  appropriate 
for  all  situations.  Lifecycle  models  are  often  used  to  define  the  phases 
of  the  project.  Also,  the  organization  may  define  different  lifecycle 
models  for  each  type  of  product  and  service  it  delivers. 
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Typical  Work  Products 

1 .  Descriptions  of  lifecycle  models 

Subpractices 

1 .  Select  lifecycle  models  based  on  the  needs  of  projects  and  the 
organization. 

For  example,  project  lifecycle  models  include  the  following: 

|  •  Waterfall 
:  •  Spiral 
i  •  Evolutionary 
|  •  Incremental 
•  Iterative 

2.  Document  the  descriptions  of  the  lifecycle  models. 

The  lifecycle  models  may  be  documented  as  part  of  the  organization’s  standard 
process  descriptions  or  they  may  be  documented  separately. 

3.  Conduct  peer  reviews  on  the  lifecycle  models. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews. 

4.  Revise  the  descriptions  of  the  lifecycle  models  as  necessary. 


SP  1.3  Establish  Tailoring  Criteria  and  Guidelines 

Establish  and  maintain  the  tailoring  criteria  and  guidelines  for 
the  organization's  set  of  standard  processes. 


IPPD  Addition 

In  creating  the  tailoring  criteria  and  guidelines,  include  considerations  for 
concurrent  development  and  operating  with  integrated  teams.  For  example, 
how  one  tailors  the  manufacturing  process  will  be  different  depending  on 
whether  it  is  developed  serially  after  the  product  has  been  developed  or  in 
parallel  with  the  development  of  the  product,  as  in  IPPD.  Processes,  such 
as  resource  allocation,  will  also  be  tailored  differently  if  the  project  is 
operating  with  integrated  teams. 
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The  tailoring  criteria  and  guidelines  describe  the  following: 

•  How  the  organization’s  set  of  standard  processes  and 
organizational  process  assets  are  used  to  create  the  defined 
processes 

•  Mandatory  requirements  that  must  be  satisfied  by  the  defined 
processes  (e.g.,  the  subset  of  the  organizational  process  assets 
that  are  essential  for  any  defined  process) 

•  Options  that  can  be  exercised  and  criteria  for  selecting  among  the 
options 

•  Procedures  that  must  be  followed  in  performing  and  documenting 
process  tailoring 

Examples  of  reasons  for  tailoring  include  the  following: 

•  Adapting  the  process  for  a  new  product  line  or  work  environment 

•  Customizing  the  process  for  a  specific  application  or  class  of  similar  applications 

•  Elaborating  the  process  description  so  that  the  resulting  defined  process  can  be 
performed 


Flexibility  in  tailoring  and  defining  processes  is  balanced  with  ensuring 
appropriate  consistency  in  the  processes  across  the  organization. 
Flexibility  is  needed  to  address  contextual  variables  such  as  the 
domain;  nature  of  the  customer;  cost,  schedule,  and  quality  tradeoffs; 
technical  difficulty  of  the  work;  and  experience  of  the  people 
implementing  the  process.  Consistency  across  the  organization  is 
needed  so  that  organizational  standards,  objectives,  and  strategies  are 
appropriately  addressed,  and  process  data  and  lessons  learned  can  be 
shared. 

Tailoring  criteria  and  guidelines  may  allow  for  using  a  standard  process 
“as  is,”  with  no  tailoring. 

Typical  Work  Products 

1 .  Tailoring  guidelines  for  the  organization's  set  of  standard 
processes 

Subpractices 

1 .  Specify  the  selection  criteria  and  procedures  for  tailoring  the 
organization's  set  of  standard  processes. 
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Examples  of  criteria  and  procedures  include  the  following: 

:  •  Criteria  for  selecting  lifecycle  models  from  those  approved  by  the  organization 

:  •  Criteria  for  selecting  process  elements  from  the  organization’s  set  of  standard 
:  processes 

|  •  Procedures  for  tailoring  the  selected  lifecycle  models  and  process  elements  to 
accommodate  specific  process  characteristics  and  needs 


Examples  of  tailoring  actions  include  the  following: 

•  Modifying  a  lifecycle  model 

•  Combining  elements  of  different  lifecycle  models 

•  Modifying  process  elements 

•  Replacing  process  elements 

•  Reordering  process  elements 


2.  Specify  the  standards  for  documenting  the  defined  processes. 

3.  Specify  the  procedures  for  submitting  and  obtaining  approval  of 
waivers  from  the  requirements  of  the  organization’s  set  of  standard 
processes. 

4.  Document  the  tailoring  guidelines  for  the  organization's  set  of 
standard  processes. 

5.  Conduct  peer  reviews  on  the  tailoring  guidelines. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews. 

6.  Revise  the  tailoring  guidelines  as  necessary. 


SP  1.4  Establish  the  Organization’s  Measurement  Repository 

Establish  and  maintain  the  organization’s  measurement 
repository. 


Refer  to  the  Use  Organizational  Process  Assets  for  Planning  Project 
Activities  specific  practice  of  the  Integrated  Project  Management 
process  area  for  more  information  about  the  use  of  the  organization’s 
measurement  repository  in  planning  project  activities. 

The  repository  contains  both  product  and  process  measures  that  are 
related  to  the  organization’s  set  of  standard  processes.  It  also  contains 
or  refers  to  the  information  needed  to  understand  and  interpret  the 
measures  and  assess  them  for  reasonableness  and  applicability.  For 
example,  the  definitions  of  the  measures  are  used  to  compare  similar 
measures  from  different  processes. 
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Typical  Work  Products 

1 .  Definition  of  the  common  set  of  product  and  process  measures  for 
the  organization’s  set  of  standard  processes 

2.  Design  of  the  organization’s  measurement  repository 

3.  Organization's  measurement  repository  (that  is,  the  repository 
structure  and  support  environment) 

4.  Organization’s  measurement  data 
Subpractices 

1 .  Determine  the  organization's  needs  for  storing,  retrieving,  and 
analyzing  measurements. 

2.  Define  a  common  set  of  process  and  product  measures  for  the 
organization's  set  of  standard  processes. 

The  measures  in  the  common  set  are  selected  based  on  the  organization’s  set  of 
standard  processes.  They  are  selected  for  their  ability  to  provide  visibility  into 
process  performance  to  support  expected  business  objectives.  The  common  set 
of  measures  may  vary  for  different  standard  processes. 

Operational  definitions  for  the  measures  specify  the  procedures  for  collecting  valid 
data  and  the  point  in  the  process  where  the  data  will  be  collected. 


Examples  of  classes  of  commonly  used  measures  include  the  following: 

•  Estimates  of  work  product  size  (e.g.,  pages) 

•  Estimates  of  effort  and  cost  (e.g.,  person  hours) 

•  Actual  measures  of  size,  effort,  and  cost 

•  Quality  measures  (e.g.,  number  of  defects  found  or  severity  of  defects) 

•  Peer  review  coverage 

•  Test  coverage 

•  Reliability  measures  (e.g.,  mean  time  to  failure) 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures. 

3.  Design  and  implement  the  measurement  repository. 

4.  Specify  the  procedures  for  storing,  updating,  and  retrieving 
measures. 

5.  Conduct  peer  reviews  on  the  definitions  of  the  common  set  of 
measures  and  the  procedures  for  storing  and  retrieving  measures. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews. 
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6.  Enter  the  specified  measures  into  the  repository. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  collecting  and  analyzing  data. 

7.  Make  the  contents  of  the  measurement  repository  available  for  use 
by  the  organization  and  projects  as  appropriate. 

8.  Revise  the  measurement  repository,  common  set  of  measures,  and 
procedures  as  the  organization’s  needs  change. 

Examples  of  when  the  common  set  of  measures  may  need  to  be  revised  include 
the  following: 

•  New  processes  are  added 

•  Processes  are  revised  and  new  measures  are  needed 

•  Finer  granularity  of  data  is  required 

•  Greater  visibility  into  the  process  is  required 

•  Measures  are  retired 

SP  1.5  Establish  the  Organization’s  Process  Asset  Library 

Establish  and  maintain  the  organization's  process  asset  library. 

.  Examples  of  items  to  be  stored  in  the  organization’s  process  asset  library  include  the 
i  following: 

|  •  Organizational  policies 

;  •  Defined  process  descriptions 

;  •  Procedures  (e.g.,  estimating  procedure) 

i  •  Development  plans 

:  •  Acquisition  plans 

:  •  Quality  assurance  plans 

:•  Training  materials 

i  •  Process  aids  (e.g.,  checklists) 

•  Lessons-learned  reports 


Typical  Work  Products 

1 .  Design  of  the  organization’s  process  asset  library 

2.  Organization's  process  asset  library 

3.  Selected  items  to  be  included  in  the  organization’s  process  asset 
library 

4.  Catalog  of  items  in  the  organization’s  process  asset  library 
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Subpractices 

1 .  Design  and  implement  the  organization’s  process  asset  library, 
including  the  library  structure  and  support  environment. 

2.  Specify  the  criteria  for  including  items  in  the  library. 

The  items  are  selected  based  primarily  on  their  relationship  to  the  organization’s 
set  of  standard  processes. 

3.  Specify  the  procedures  for  storing  and  retrieving  items. 

4.  Enter  the  selected  items  into  the  library  and  catalog  them  for  easy 
reference  and  retrieval. 

5.  Make  the  items  available  for  use  by  the  projects. 

6.  Periodically  review  the  use  of  each  item  and  use  the  results  to 
maintain  the  library  contents. 

7.  Revise  the  organization’s  process  asset  library  as  necessary. 

Examples  of  when  the  library  may  need  to  be  revised  include  the  following: 

•  New  items  are  added 

•  Items  are  retired 

•  Current  versions  of  items  are  changed 

SP  1.6  Establish  Work  Environment  Standards 

Establish  and  maintain  work  environment  standards. 


Work  environment  standards  allow  the  organization  and  projects  to 
benefit  from  common  tools,  training,  and  maintenance,  as  well  as  cost 
savings  from  volume  purchases.  Work  environment  standards  address 
the  needs  of  all  stakeholders  and  consider  productivity,  cost, 
availability,  security,  and  workplace  health,  safety,  and  ergonomic 
factors.  Work  environment  standards  can  include  guidelines  for  tailoring 
and/or  the  use  of  waivers  that  allow  adaptation  of  the  project’s  work 
environment  to  meet  specific  needs. 


Examples  of  work  environment  standards  include 

•  Procedures  for  operation,  safety,  and  security  of  the  work  environment 

•  Standard  workstation  hardware  and  software 

•  Standard  application  software  and  tailoring  guidelines  for  it 

•  Standard  production  and  calibration  equipment 

•  Process  for  requesting  and  approving  tailoring  or  waivers 


Typical  Work  Products 

1 .  Work  environment  standards 
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Subpractices 

1 .  Evaluate  commercially-available  work  environment  standards 
appropriate  for  the  organization. 

2.  Adopt  existing  work  environment  standards  and  develop  new  ones 
to  fill  gaps  based  on  the  organization’s  process  needs  and 
objectives. 


IPPD  Addition 

SG  2  Enable  IPPD  Management 

Organizational  rules  and  guidelines,  which  govern  the  operation  of 
integrated  teams,  are  provided. 

An  organizational  infrastructure  that  supports  and  promotes  IPPD 
concepts  is  critical  if  it  is  to  be  successfully  sustained  over  the  long 
term.  These  rules  and  guidelines  promote  concepts  such  as  integrated 
teaming  and  allow  for  empowered  decision  making  at  many  levels. 
Through  its  rules  and  guidelines,  the  organization  demonstrates 
commitment  to  IPPD  and  the  success  of  its  integrated  teams. 

IPPD  rules  and  guidelines  become  part  of  the  organization’s  set  of 
standard  processes  and  the  project’s  defined  process.  The 
organization’s  standard  processes  enable,  promote,  and  reinforce  the 
behaviors  expected  from  projects,  integrated  teams,  and  people.  These 
expected  behaviors  are  typically  communicated  in  the  form  of  policies, 
operating  procedures,  guidelines,  and  other  organizational  process 
assets. 

SP  2.1  Establish  Empowerment  Mechanisms 

Establish  and  maintain  empowerment  mechanisms  to  enable 
timely  decision  making. 

In  a  successful  IPPD  environment,  clear  channels  of  responsibility  and 
authority  must  be  established.  Issues  can  arise  at  any  level  of  the 
organization  when  integrated  teams  assume  too  much  or  too  little 
authority  and  when  it  is  unclear  who  is  responsible  for  making 
decisions.  Documenting  and  deploying  organizational  guidelines  that 
clearly  define  the  empowerment  of  integrated  teams  can  prevent  these 
issues. 
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IPPD  Addition 

Implementing  IPPD  introduces  challenges  to  leadership  because  of  the 
cultural  changes  required  when  people  and  integrated  teams  are 
empowered  and  decisions  are  driven  to  the  lowest  level  appropriate. 
Effective  and  efficient  communication  mechanisms  are  critical  to  timely 
and  sound  decision  making  in  the  integrated  work  environment.  Once 
an  integrated  team  project  structure  is  established  and  training  is 
provided,  mechanisms  to  handle  empowerment,  decision  making,  and 
issue  resolution  also  need  to  be  provided. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  decision  making. 


Typical  Work  Products 

1 .  Empowerment  rules  and  guidelines  for  people  and  integrated 
teams 

2.  Decision-making  rules  and  guidelines 

3.  Issue  resolution  documentation 

Subpractices 

1 .  Determine  rules  and  guidelines  for  the  degree  of  empowerment 
provided  to  people  and  integrated  teams. 


Factors  to  consider  regarding  integrated  team  empowerment  include  the 
following: 

•  Authority  of  teams  to  pick  their  own  leader 

•  Authority  of  teams  to  implement  subteams  (e.g.,  a  product  team  forming  an 
integration  subteam) 

•  The  degree  of  collective  decision  making 

•  The  level  of  consensus  needed  for  integrated  team  decisions 

•  How  conflicts  and  differences  of  opinion  within  the  integrated  teams  are 
addressed  and  resolved 


2.  Determine  rules  and  guidelines  for  the  use  of  different  decision 
types  in  making  various  kinds  of  team  decisions. 

3.  Define  the  process  for  using  the  decision-making  rules  and 
guidelines. 

4.  Define  a  process  for  issue  resolution  when  an  issue  cannot  be 
decided  at  the  level  at  which  it  arose. 
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IPPD  Addition 

Refer  to  the  Resolve  Coordination  Issues  specific  practice  in  the 
Integrated  Project  Management  process  area  for  more  information 
about  resolving  issues  with  relevant  stakeholders. 

5.  Maintain  the  empowerment  mechanisms  and  the  rules  and 
guidelines  for  decision  making. 

SP  2.2  Establish  Rules  and  Guidelines  for  Integrated  Teams 

Establish  and  maintain  organizational  rules  and  guidelines  for 
structuring  and  forming  integrated  teams. 


Operating  rules  and  guidelines  for  the  integrated  teams  define  and 
control  how  teams  interact  to  accomplish  objectives.  These  rules  and 
guidelines  also  promote  the  effective  leveraging  of  the  teams’  efforts, 
high  performance,  and  productivity.  Integrated  team  members  must 
understand  the  standards  for  work  and  participate  according  to  those 
standards. 

Typical  Work  Products 

1 .  Rules  and  guidelines  for  the  structuring  and  formation  of  integrated 
teams 

Subpractices 

1 .  Establish  rules  and  guidelines  for  structuring  and  forming 
integrated  teams. 


:  Organizational  process  assets  can  help  the  project  to  structure  and  implement 
:  integrated  teams.  Such  assets  may  include  the  following: 

:•  Team  structure  guidelines 
|  •  Team  formation  guidelines 
:  •  Team  authority  and  responsibility  guidelines 
:•  IPPD  implementation  techniques 
|  •  Guidelines  for  managing  risks  in  IPPD 
:  •  Guidelines  for  establishing  lines  of  communication  and  authority 
:•  Team  leader  selection  criteria 
•  Team  responsibility  guidelines 
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IPPD  Addition 

2.  Define  the  expectations,  rules,  and  guidelines  that  will  guide  how 
the  integrated  teams  work  collectively. 

These  rules  and  guidelines  establish  organizational  practices  for  consistency 
across  integrated  teams  and  can  include  the  following: 

•  How  interfaces  among  integrated  teams  are  established  and  maintained 

•  How  assignments  are  accepted 

•  How  resources  and  input  are  accessed 

•  How  work  gets  done 

•  Who  checks,  reviews,  and  approves  work 

•  How  work  is  approved 

•  How  work  is  delivered  and  communicated 

•  Reporting  chains 

•  Reporting  requirements  (cost,  schedule,  and  performance  status),  measures,  and 
methods 

•  Progress  reporting  measures  and  methods 

3.  Maintain  the  rules  and  guidelines  for  structuring  and  forming 
integrated  teams. 

SP  2.3  Balance  Team  and  Home  Organization  Responsibilities 

Establish  and  maintain  organizational  guidelines  to  help  team 
members  balance  their  team  and  home  organization 
responsibilities. 

A  “home  organization”  is  the  part  of  the  organization  to  which  team 
members  are  assigned  when  they  are  not  on  an  integrated  team.  A 
home  organization  may  be  called  a  “functional  organization,”  “home 
base,”  “home  office,”  or  “direct  organization.”  Home  organizations  are 
often  responsible  for  the  career  growth  of  their  members  (e.g., 
performance  appraisals  and  training  to  maintain  functional  and 
discipline  expertise). 

In  an  IPPD  environment,  reporting  procedures  and  rating  systems 
assume  that  members’  responsibilities  are  focused  on  the  integrated 
team,  not  on  the  home  organization.  However,  the  responsibility  of 
integrated  team  members  to  their  home  organizations  is  also  important, 
specifically  for  process  implementation  and  improvement.  Workloads 
and  responsibilities  should  be  balanced  between  projects  and  functions, 
and  career  growth  and  advancement.  Organizational  mechanisms 
should  exist  that  support  the  home  organization  while  aligning  the 
workforce  to  meet  business  objectives  in  a  teaming  environment. 
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IPPD  Addition 

Sometimes  teams  persist  beyond  their  productive  life  in  organizations 
that  do  not  have  a  home  organization  for  the  team  members  to  return  to 
after  the  integrated  the  team  is  dissolved.  Therefore,  there  should  be 
guidelines  for  disbanding  the  integrated  teams  and  maintaining  home 
organizations. 

Typical  Work  Products 

1. 

Organizational  guidelines  for  balancing  team  and  home 
organization  responsibilities 

2. 

Performance  review  process  that  considers  both  functional 
supervisor  and  team  leader  input 

Subpractices 

1. 

Establish  guidelines  for  home  organization  responsibilities  that 
promote  integrated  team  behavior. 

2. 

Establish  guidelines  for  team  management  responsibilities  to 
ensure  integrated  team  members  report  appropriately  to  their  home 
organizations. 

3. 

Establish  a  performance  review  process  that  considers  input  from 
both  home  organization  and  integrated  team  leaders. 

4. 

Maintain  the  guidelines  for  balancing  team  and  home  organization 
responsibilities. 

Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  organizational  process 
definition  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 
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Continuous  Only 

GG  2  Institutionalize  a  Managed  Process 

_ The  process  is  institutionalized  as  a  managed  process. 


Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  organizational  process  definition  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  a  set  of  standard  processes  for  use  by  the  organization  and 
making  organizational  process  assets  available  across  the  organization. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
organizational  process  definition  process. 


Elaboration: 

This  plan  for  performing  the  organizational  process  definition  process 
can  be  part  of  (or  referenced  by)  the  organization’s  process 
improvement  plan. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
process  definition  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 


Elaboration: 

A  process  group  typically  manages  the  organizational  process  definition 
activities.  This  group  typically  is  staffed  by  a  core  of  professionals 
whose  primary  responsibility  is  coordinating  organizational  process 
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improvement.  This  group  is  supported  by  process  owners  and  people 
with  expertise  in  various  disciplines  such  as  the  following: 

•  Project  management 

•  The  appropriate  engineering  disciplines 

•  Configuration  management 

•  Quality  assurance 

Examples  of  other  resources  provided  include  the  following  tools: 

I  •  Database  management  systems 

:  •  Process  modeling  tools 

•  Web  page  builders  and  browsers 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  organizational  process  definition  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
process  definition  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 

|  •  CMMI  and  other  process  and  process  improvement  reference  models 
|  •  Planning,  managing,  and  monitoring  processes 
:  •  Process  modeling  and  definition 
:  •  Developing  a  tailorable  standard  process 
:  •  Developing  work  environment  standards 
•  Ergonomics 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  process 
definition  process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Organization’s  set  of  standard  processes 
I  •  Descriptions  of  the  lifecycle  models 

j  •  Tailoring  guidelines  for  the  organization’s  set  of  standard  processes 
j  •  Definitions  of  the  common  set  of  product  and  process  measures 
•  Organization’s  measurement  data 


IPPD  Addition 

Examples  of  work  products  placed  under  control  include  the  following: 

•  Empowerment  rules  and  guidelines  for  people  and  integrated  teams 

•  Organizational  process  documentation  for  issue  resolution 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
organizational  process  definition  process  as  planned. 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following: 

:  •  Reviewing  the  organization’s  set  of  standard  processes 
:  •  Reviewing  the  organization’s  lifecycle  models 
i  •  Resolving  issues  on  the  tailoring  guidelines 

i  •  Assessing  the  definitions  of  the  common  set  of  process  and  product  measures 
:  •  Reviewing  the  work  environment  standards 


IPPD  Addition 

Examples  of  activities  for  stakeholder  involvement  also  include  the 
following: 

•  Establishing  and  maintaining  IPPD  empowerment  mechanisms 

•  Establishing  and  maintaining  organizational  rules  and  guidelines  for  the 
structuring  and  forming  of  integrated  teams 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  process  definition 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 
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Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Percentage  of  projects  using  the  process  architectures  and  process  elements  of 
the  organization’s  set  of  standard  processes 

•  Defect  density  of  each  process  element  of  the  organization’s  set  of  standard 
processes 

•  Number  of  worker's  compensation  claims  due  to  ergonomic  problems 

•  Schedule  for  development  of  a  process  or  process  change 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  process 
definition  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance. 


Elaboration: 


Examples  of  activities  reviewed  include  the  following: 
•  Establishing  organizational  process  assets 


IPPD  Addition 

Examples  of  activities  reviewed  also  include  the  following: 

•  Determining  rules  and  guidelines  for  the  degree  of  empowerment 
provided  to  people  and  integrated  teams 

•  Establishing  and  maintaining  an  issue  resolution  process 

Examples  of  work  products  reviewed  include  the  following: 

•  Organization’s  set  of  standard  processes 

•  Descriptions  of  the  lifecycle  models 

•  T ailoring  guidelines  for  the  organization’s  set  of  standard  processes 

•  Organization’s  measurement  data 


IPPD  Addition 

Examples  of  work  products  reviewed  also  include  the  following: 

•  Empowerment  rules  and  guidelines  for  people  and  integrated  teams 

•  Organizational  process  documentation 
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GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
process  definition  process  with  higher  level  management  and 
resolve  issues. 


Continuous  Only 

GG  3  institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
organizational  process  definition  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  organizational  process  definition  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Submission  of  lessons  learned  to  the  organization's  process  asset  library 

•  Submission  of  measurement  data  to  the  organization's  measurement  repository 

•  Status  of  the  change  requests  submitted  to  modify  the  organization's  standard 
process 

•  Record  of  non-standard  tailoring  requests 

IPPD  Addition 

Examples  of  work  products,  measures,  measurement  results,  and 
improvement  information  also  include  the  following: 

•  Status  of  performance  review  input  from  integrated  teams 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  process  definition  process,  which  address 
quality  and  process  performance,  based  on  customer  needs 
and  business  objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  process  definition 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  process 
definition  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  organizational  process  definition  process. 
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ORGANIZATIONAL  PROCESS  FOCUS 


A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Process  Focus  (OPF)  is  to  plan, 
implement,  and  deploy  organizational  process  improvements  based  on 
a  thorough  understanding  of  the  current  strengths  and  weaknesses  of 
the  organization’s  processes  and  process  assets. 


Introductory  Notes 


The  organization's  processes  include  all  the  processes  used  by  the 
organization  and  its  projects.  Candidate  improvements  to  the 
organization's  processes  and  process  assets  are  obtained  from  various 
sources,  including  measurement  of  the  processes,  lessons  learned  in 
implementing  the  processes,  results  of  process  appraisals,  results  of 
product  evaluation  activities,  results  of  benchmarking  against  other 
organizations’  processes,  and  recommendations  from  other 
improvement  initiatives  in  the  organization. 

Process  improvement  occurs  within  the  context  of  the  organization’s 
needs  and  is  used  to  address  the  organization’s  objectives.  The 
organization  encourages  participation  in  process  improvement  activities 
by  those  who  will  perform  the  process.  The  responsibility  for  facilitating 
and  managing  the  organization’s  process  improvement  activities, 
including  coordinating  the  participation  of  others,  is  typically  assigned  to 
a  process  group.  The  organization  provides  the  long-term  commitment 
and  resources  required  to  sponsor  this  group  and  to  ensure  the 
effective  and  timely  deployment  of  the  improvements. 

Careful  planning  is  required  to  ensure  that  process  improvement  efforts 
across  the  organization  are  adequately  managed  and  implemented. 

The  organization’s  planning  for  process  improvement  results  in  a 
process  improvement  plan. 

The  organization’s  process  improvement  plan  will  address  appraisal 
planning,  process  action  planning,  pilot  planning,  and  deployment 
planning.  Appraisal  plans  describe  the  appraisal  timeline  and  schedule, 
the  scope  of  the  appraisal,  the  resources  required  to  perform  the 
appraisal,  the  reference  model  against  which  the  appraisal  will  be 
performed,  and  the  logistics  for  the  appraisal. 

Process  action  plans  usually  result  from  appraisals  and  document  how 
specific  improvements  targeting  the  weaknesses  uncovered  by  an 
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appraisal  will  be  implemented.  In  cases  in  which  it  is  determined  that 
the  improvement  described  in  the  process  action  plan  should  be  tested 
on  a  small  group  before  deploying  it  across  the  organization,  a  pilot  plan 
is  generated. 

Finally,  when  the  improvement  is  to  be  deployed,  a  deployment  plan  is 
used.  This  plan  describes  when  and  how  the  improvement  will  be 
deployed  across  the  organization. 

Organizational  process  assets  are  used  to  describe,  implement,  and 
improve  the  organization's  processes  (see  the  definition  of 
“organizational  process  assets”  in  the  glossary). 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets. 

Specific  Goal  and  Practice  Summary 

SG  1  Determine  Process  Improvement  Opportunities 

SP  1.1  Establish  Organizational  Process  Needs 
SP  1 .2  Appraise  the  Organization’s  Processes 
SP  1 .3  Identify  the  Organization's  Process  Improvements 
SG  2  Plan  and  Implement  Process  Improvements 
SP  2.1  Establish  Process  Action  Plans 

SP  2.2  Implement  Process  Action  Plans 

SG  3  Deploy  Organizational  Process  Assets  and  Incorporate  Lessons  Learned 
SP  3.1  Deploy  Organizational  Process  Assets 

SP  3.2  Deploy  Standard  Processes 

SP  3.3  Monitor  Implementation 

SP  3.4  Incorporate  Process-Related  Experiences  into  the  Organizational  Process  Assets 

Specific  Practices  by  Goal 


SG  1  Determine  Process  Improvement  Opportunities 

Strengths,  weaknesses,  and  improvement  opportunities  for  the 
organization's  processes  are  identified  periodically  and  as  needed. 

Strengths,  weaknesses,  and  improvement  opportunities  may  be 
determined  relative  to  a  process  standard  or  model  such  as  a  CMMI 
model  or  International  Organization  for  Standardization  (ISO)  standard. 
The  process  improvements  should  be  selected  specifically  to  address 
the  organization’s  needs. 

SP  1.1  Establish  Organizational  Process  Needs 

Establish  and  maintain  the  description  of  the  process  needs 
and  objectives  for  the  organization. 
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IPPD  Addition 

Integrated  processes  that  emphasize  parallel  rather  than  serial 
development  are  a  cornerstone  of  IPPD  implementation.  The  processes  for 
developing  the  product  and  for  developing  product-related  lifecycle 
processes,  such  as  the  manufacturing  process  and  the  support  process 
processes,  are  integrated  and  conducted  concurrently.  Such  integrated 
processes  need  to  accommodate  the  information  provided  by  stakeholders 
representing  all  phases  of  the  product  lifecycle  from  both  business  and 
technical  functions.  Processes  for  effective  teamwork  will  also  be  needed. 


IPPD  Addition 

Examples  of  processes  for  effective  teamwork  include  the  following: 

•  Communications 

•  Collaborative  decision  making 

•  Issue  resolution 

•  Team  building 


The  organization’s  processes  operate  in  a  business  context  that  must 
be  understood.  The  organization’s  business  objectives,  needs,  and 
constraints  determine  the  needs  and  objectives  for  the  organization’s 
processes.  Typically,  the  issues  related  to  finance,  technology,  quality, 
human  resources,  and  marketing  are  important  process  considerations. 

The  organization’s  process  needs  and  objectives  cover  aspects  that 
include  the  following: 

•  Characteristics  of  the  processes 

•  Process-performance  objectives,  such  as  time-to-market  and 
delivered  quality 

•  Process  effectiveness 

Typical  Work  Products 

1 .  Organization’s  process  needs  and  objectives 
Subpractices 

1 .  Identify  the  policies,  standards,  and  business  objectives  that  are 
applicable  to  the  organization's  processes. 

2.  Examine  relevant  process  standards  and  models  for  best  practices. 

3.  Determine  the  organization’s  process-performance  objectives. 

Process-performance  objectives  may  be  expressed  in  quantitative  or  qualitative 
terms. 
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Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurement  objectives. 

Examples  of  process-performance  objectives  include  the  following: 

i  •  Cycle  time 
j  •  Defect  removal  rates 
:  •  Productivity 

4.  Define  the  essential  characteristics  of  the  organization’s  processes. 

The  essential  characteristics  of  the  organization’s  processes  are  determined 
based  on  the  following: 

•  Processes  currently  being  used  in  the  organization 

•  Standards  imposed  by  the  organization 

•  Standards  commonly  imposed  by  customers  of  the  organization 

Examples  of  process  characteristics  include  the  following: 

j  •  Level  of  detail  used  to  describe  the  processes 
j  •  Process  notation  used 
:  •  Granularity  of  the  processes 

5.  Document  the  organization’s  process  needs  and  objectives. 

6.  Revise  the  organization’s  process  needs  and  objectives  as 
needed. 

SP  1.2  Appraise  the  Organization’s  Processes 

Appraise  the  organization's  processes  periodically  and  as 
needed  to  maintain  an  understanding  of  their  strengths  and 
weaknesses. 

Process  appraisals  may  be  performed  for  the  following  reasons: 

•  To  identify  processes  that  should  be  improved 

•  To  confirm  progress  and  make  the  benefits  of  process  improvement 
visible 

•  To  satisfy  the  needs  of  a  customer-supplier  relationship 

•  To  motivate  and  facilitate  buy-in 

The  buy-in  gained  during  a  process  appraisal  can  be  eroded 
significantly  if  it  is  not  followed  by  an  appraisal-based  action  plan. 

Typical  Work  Products 

1 .  Plans  for  the  organization's  process  appraisals 
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2.  Appraisal  findings  that  address  strengths  and  weaknesses  of  the 
organization's  processes 

3.  Improvement  recommendations  for  the  organization's  processes 
Subpractices 

1 .  Obtain  sponsorship  of  the  process  appraisal  from  senior 
management. 

Senior  management  sponsorship  includes  the  commitment  to  have  the 
organization's  managers  and  staff  participate  in  the  process  appraisal  and  to 
provide  the  resources  and  funding  to  analyze  and  communicate  the  findings  of  the 
appraisal. 

2.  Define  the  scope  of  the  process  appraisal. 

Process  appraisals  may  be  performed  on  the  entire  organization  or  may  be 
performed  on  a  smaller  part  of  an  organization  such  as  a  single  project  or 
business  area. 

The  scope  of  the  process  appraisal  addresses  the  following: 

•  Definition  of  the  organization  (e.g.,  sites  or  business  areas)  that  will  be  covered  by 
the  appraisal 

•  Identification  of  the  project  and  support  functions  that  will  represent  the 
organization  in  the  appraisal 

•  Processes  that  will  be  appraised 

3.  Determine  the  method  and  criteria  for  process  appraisal. 

Process  appraisals  can  occur  in  many  forms.  Process  appraisals  should  address 
the  needs  and  objectives  of  the  organization,  which  may  change  over  time.  For 
example,  the  appraisal  may  be  based  on  a  process  model,  such  as  a  CMMI 
model,  or  on  a  national  or  international  standard,  such  as  ISO  9001  [ISO  2000], 
The  appraisals  may  also  be  based  on  a  benchmark  comparison  with  other 
organizations.  The  appraisal  method  may  assume  a  variety  of  characteristics  in 
terms  of  time  and  effort  expended,  makeup  of  the  appraisal  team,  and  the  method 
and  depth  of  investigation. 

4.  Plan,  schedule,  and  prepare  for  the  process  appraisal. 

5.  Conduct  the  process  appraisal. 

6.  Document  and  deliver  the  appraisal’s  activities  and  findings. 


SP  1.3  Identify  the  Organization's  Process  Improvements 

Identify  improvements  to  the  organization's  processes  and 
process  assets. 


Typical  Work  Products 

1 .  Analysis  of  candidate  process  improvements 
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2.  Identification  of  improvements  for  the  organization's  processes 
Subpractices 

1.  Determine  candidate  process  improvements. 

Candidate  process  improvements  are  typically  determined  by  doing  the  following: 

•  Measure  the  processes  and  analyze  the  measurement  results 

•  Review  the  processes  for  effectiveness  and  suitability 

•  Review  the  lessons  learned  from  tailoring  the  organization’s  set  of  standard 
processes 

•  Review  the  lessons  learned  from  implementing  the  processes 

•  Review  process  improvement  proposals  submitted  by  the  organization’s 
managers,  staff,  and  other  relevant  stakeholders 

•  Solicit  inputs  on  process  improvements  from  senior  management  and  leaders  in 
the  organization 

•  Examine  the  results  of  process  appraisals  and  other  process-related  reviews 

•  Review  results  of  other  organizational  improvement  initiatives 

2.  Prioritize  the  candidate  process  improvements. 

Criteria  for  prioritization  are  as  follows: 

•  Consider  the  estimated  cost  and  effort  to  implement  the  process  improvements 

•  Appraise  the  expected  improvement  against  the  organization’s  improvement 
objectives  and  priorities 

•  Determine  the  potential  barriers  to  the  process  improvements  and  develop 
strategies  for  overcoming  these  barriers 

Examples  of  techniques  to  help  determine  and  prioritize  the  possible 
:  improvements  to  be  implemented  include  the  following: 

j  •  A  gap  analysis  that  compares  current  conditions  in  the  organization  with  optimal 
j  conditions 

j  •  Force-field  analysis  of  potential  improvements  to  identify  potential  barriers  and 
j  strategies  for  overcoming  those  barriers 

:  •  Cause-and-effect  analyses  to  provide  information  on  the  potential  effects  of 
different  improvements  that  can  then  be  compared 


3.  Identify  and  document  the  process  improvements  that  will  be 
implemented. 

4.  Revise  the  list  of  planned  process  improvements  to  keep  it  current. 
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SG  2  Plan  and  Implement  Process  Improvements 

Process  actions  that  address  improvements  to  the  organization’s 
processes  and  process  assets  are  planned  and  implemented. 

Successful  implementation  of  improvements  requires  participation  in 
process  action  planning  and  implementation  by  process  owners,  those 
performing  the  process,  and  support  organizations. 


SP  2.1  Establish  Process  Action  Plans 

Establish  and  maintain  process  action  plans  to  address 
improvements  to  the  organization's  processes  and  process 
assets. 


Establishing  and  maintaining  process  action  plans  typically  involves  the 
following  roles: 

•  Management  steering  committees  to  set  strategies  and  oversee 
process  improvement  activities 

•  Process  group  staff  to  facilitate  and  manage  process  improvement 
activities 

•  Process  action  teams  to  define  and  implement  process  actions 

•  Process  owners  to  manage  deployment 

•  Practitioners  to  perform  the  process 

This  involvement  helps  to  obtain  buy-in  on  the  process  improvements 
and  increases  the  likelihood  of  effective  deployment. 

Process  action  plans  are  detailed  implementation  plans.  These  plans 
differ  from  the  organization’s  process  improvement  plan  in  that  they  are 
plans  targeting  specific  improvements  that  have  been  defined  to 
address  weaknesses  usually  uncovered  by  appraisals. 

Typical  Work  Products 

1.  Organization's  approved  process  action  plans 
Subpractices 

1 .  Identify  strategies,  approaches,  and  actions  to  address  the 
identified  process  improvements. 

New,  unproven,  and  major  changes  are  piloted  before  they  are  incorporated  into 
normal  use. 

2.  Establish  process  action  teams  to  implement  the  actions. 

The  teams  and  people  performing  the  process  improvement  actions  are  called 
“process  action  teams.”  Process  action  teams  typically  include  process  owners 
and  those  who  perform  the  process. 

3.  Document  process  action  plans. 
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Process  action  plans  typically  cover  the  following: 

•  Process  improvement  infrastructure 

•  Process  improvement  objectives 

•  Process  improvements  that  will  be  addressed 

•  Procedures  for  planning  and  tracking  process  actions 

•  Strategies  for  piloting  and  implementing  the  process  actions 

•  Responsibility  and  authority  for  implementing  the  process  actions 

•  Resources,  schedules,  and  assignments  for  implementing  the  process  actions 

•  Methods  for  determining  the  effectiveness  of  the  process  actions 

•  Risks  associated  with  process  action  plans 

4.  Review  and  negotiate  process  action  plans  with  relevant 
stakeholders. 

5.  Review  process  action  plans  as  necessary. 

SP  2.2  Implement  Process  Action  Plans 

Implement  process  action  plans. 


Typical  Work  Products 

1 .  Commitments  among  the  various  process  action  teams 

2.  Status  and  results  of  implementing  process  action  plans 

3.  Plans  for  pilots 

Subpractices 

1 .  Make  process  action  plans  readily  available  to  relevant 
stakeholders. 

2.  Negotiate  and  document  commitments  among  the  process  action 
teams  and  revise  their  process  action  plans  as  necessary. 

3.  Track  progress  and  commitments  against  process  action  plans. 

4.  Conduct  joint  reviews  with  the  process  action  teams  and  relevant 
stakeholders  to  monitor  the  progress  and  results  of  the  process 
actions. 

5.  Plan  pilots  needed  to  test  selected  process  improvements. 

6.  Review  the  activities  and  work  products  of  process  action  teams. 

7.  Identify,  document,  and  track  to  closure  issues  in  implementing 
process  action  plans. 

8.  Ensure  that  the  results  of  implementing  process  action  plans 
satisfy  the  organization’s  process  improvement  objectives. 
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Deploy  Organizational  Process  Assets  and  Incorporate  Lessons  Learned 
The  organizational  process  assets  are  deployed  across  the  organization 
and  process-related  experiences  are  incorporated  into  the  organizational 
process  assets. 

The  specific  practices  within  this  specific  goal  describe  ongoing 
activities.  New  opportunities  to  benefit  from  the  organizational  process 
assets  and  changes  to  them  may  arise  throughout  the  life  of  each 
project.  Deployment  of  the  standard  processes  and  other  organizational 
process  assets  must  be  continually  supported  within  the  organization, 
particularly  for  new  projects  at  startup. 


SP  3.1  Deploy  Organizational  Process  Assets 

Deploy  organizational  process  assets  across  the  organization. 


Deploying  organizational  process  assets  or  changes  to  organizational 
process  assets  should  be  performed  in  an  orderly  manner.  Some 
organizational  process  assets  or  changes  to  organizational  process 
assets  may  not  be  appropriate  for  use  in  some  parts  of  the  organization 
(because  of  customer  requirements  or  the  current  lifecycle  phase  being 
implemented,  for  example).  It  is  therefore  important  that  those  that  are 
or  will  be  executing  the  process,  as  well  as  other  organization  functions 
(such  as  training  and  quality  assurance),  be  involved  in  the  deployment 
as  necessary. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  how  the  deployment  of  organizational  process  assets 
is  supported  and  enabled  by  the  organization’s  process  asset  library. 

Typical  Work  Products 

1 .  Plans  for  deploying  organizational  process  assets  and  changes  to 
them  across  the  organization 

2.  Training  materials  for  deploying  organizational  process  assets  and 
changes  to  them 

3.  Documentation  of  changes  to  organizational  process  assets 

4.  Support  materials  for  deploying  organizational  process  assets  and 
changes  to  them 

Subpractices 

1 .  Deploy  organizational  process  assets  across  the  organization. 

Typical  activities  performed  as  a  part  of  this  deployment  include  the  following: 

•  Identifying  the  organizational  process  assets  that  should  be  adopted  by  those  who 
perform  the  process 

•  Determining  how  the  organizational  process  assets  are  made  available  (e.g.,  via 
Web  site) 
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•  Identifying  how  changes  to  the  organizational  process  assets  are  communicated 

•  Identifying  the  resources  (e.g.,  methods  and  tools)  needed  to  support  the  use  of 
the  organizational  process  assets 

•  Planning  the  deployment 

•  Assisting  those  who  use  the  organizational  process  assets 

•  Ensuring  that  training  is  available  for  those  who  use  the  organizational  process 
assets 

Refer  to  the  Organizational  Training  process  area  for  more 
information  about  coordination  of  training. 

2.  Document  the  changes  to  the  organizational  process  assets. 

Documenting  changes  to  the  organizational  process  assets  serves  two  main 
purposes: 

•  To  enable  communication  of  the  changes 

•  To  understand  the  relationship  of  changes  in  the  organizational  process  assets  to 
changes  in  process  performance  and  results 

3.  Deploy  the  changes  that  were  made  to  the  organizational  process 
assets  across  the  organization. 

Typical  activities  performed  as  a  part  of  deploying  changes  include  the  following: 

•  Determining  which  changes  are  appropriate  for  those  who  perform  the  process 

•  Planning  the  deployment 

•  Arranging  for  the  associated  support  needed  to  successfully  transition  the 
changes 

4.  Provide  guidance  and  consultation  on  the  use  of  the  organizational 
process  assets. 


SP  3.2  Deploy  Standard  Processes 

Deploy  the  organization’s  set  of  standard  processes  to  projects 
at  their  startup  and  deploy  changes  to  them  as  appropriate 
throughout  the  life  of  each  project. 


It  is  important  that  new  projects  use  proven  and  effective  processes  to 
perform  critical  early  activities  (e.g.,  project  planning,  receiving 
requirements,  and  obtaining  resources). 

Projects  should  also  periodically  update  their  defined  processes  to 
incorporate  the  latest  changes  made  to  the  organization’s  set  of 
standard  processes  when  it  will  benefit  them.  This  periodic  updating 
helps  to  ensure  that  all  project  activities  derive  the  full  benefit  of  what 
other  projects  have  learned. 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 

information  about  the  organization’s  set  of  standard  processes  and 

tailoring  guidelines. 

Typical  Work  Products 

1 .  Organization's  list  of  projects  and  status  of  process  deployment  on 
each  project  (i.e. ,  existing  and  planned  projects) 

2.  Guidelines  for  deploying  the  organization’s  set  of  standard 
processes  on  new  projects 

3.  Records  of  tailoring  the  organization’s  set  of  standard  processes 
and  implementing  them  on  identified  projects 

Subpractices 

1 .  Identify  projects  within  the  organization  that  are  starting  up. 

2.  Identify  active  projects  that  would  benefit  from  implementing  the 
organization’s  current  set  of  standard  processes. 

3.  Establish  plans  to  implement  the  organization’s  current  set  of 
standard  processes  on  the  identified  projects. 

4.  Assist  projects  in  tailoring  the  organization’s  set  of  standard 
processes  to  meet  project  needs. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  tailoring  the  organization’s  set  of  standard 
processes  to  meet  the  unique  needs  and  objectives  of  the  project. 

5.  Maintain  records  of  tailoring  and  implementing  processes  on  the 
identified  projects. 

6.  Ensure  that  the  defined  processes  resulting  from  process  tailoring 
are  incorporated  into  the  plans  for  process-compliance  audits. 

Process-compliance  audits  address  objective  evaluations  of  project  activities 
against  the  project’s  defined  processes. 

7.  As  the  organization’s  set  of  standard  processes  are  updated, 
identify  which  projects  should  implement  the  changes. 

SP  3.3  Monitor  Implementation 

Monitor  the  implementation  of  the  organization’s  set  of 

standard  processes  and  use  of  process  assets  on  all  projects. 


By  monitoring  implementation,  the  organization  ensures  that  the 
organization’s  set  of  standard  processes  and  other  process  assets  are 
appropriately  deployed  to  all  projects.  Monitoring  implementation  also 
helps  the  organization  develop  an  understanding  of  the  organizational 
process  assets  being  used  and  where  they  are  used  within  the 
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organization.  Monitoring  also  helps  to  establish  a  broader  context  for 
interpreting  and  using  process  and  product  measures,  lessons  learned, 
and  improvement  information  obtained  from  projects. 

Typical  Work  Products 

1 .  Results  of  monitoring  process  implementation  on  projects 

2.  Status  and  results  of  process-compliance  evaluations 

3.  Results  of  reviewing  selected  process  artifacts  created  as  part  of 
process  tailoring  and  implementation 

Subpractices 

1 .  Monitor  projects  for  their  use  of  the  organization’s  process  assets 
and  changes  to  them. 

2.  Review  selected  process  artifacts  created  during  the  life  of  each 
project. 

Reviewing  selected  process  artifacts  created  during  the  life  of  a  project  ensures 
that  all  projects  are  making  appropriate  use  of  the  organization’s  set  of  standard 
processes. 

3.  Review  the  results  of  process-compliance  evaluations  to  determine 
how  well  the  organization’s  set  of  standard  processes  has  been 
deployed. 

Refer  to  the  Process  and  Product  Quality  Assurance  process  area 
for  more  information  about  objectively  evaluating  processes 
against  applicable  process  descriptions,  standards,  and 
procedures. 

4.  Identify,  document,  and  track  to  closure  issues  related  to 
implementing  the  organization’s  set  of  standard  processes. 

SP  3.4  Incorporate  Process-Related  Experiences  into  the  Organizational 
Process  Assets 

Incorporate  process-related  work  products,  measures,  and 
improvement  information  derived  from  planning  and 
performing  the  process  into  the  organizational  process  assets. 

Typical  Work  Products 

1 .  Process  improvement  proposals 

2.  Process  lessons  learned 

3.  Measurements  on  the  organizational  process  assets 

4.  Improvement  recommendations  for  the  organizational  process 
assets 
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5.  Records  of  the  organization's  process  improvement  activities 

6.  Information  on  the  organizational  process  assets  and 
improvements  to  them 

Subpractices 

1 .  Conduct  periodic  reviews  of  the  effectiveness  and  suitability  of  the 
organization’s  set  of  standard  processes  and  related  organizational 
process  assets  relative  to  the  organization’s  business  objectives. 

2.  Obtain  feedback  about  the  use  of  the  organizational  process 
assets. 

3.  Derive  lessons  learned  from  defining,  piloting,  implementing,  and 
deploying  the  organizational  process  assets. 

4.  Make  available  lessons  learned  to  the  people  in  the  organization  as 
appropriate. 

Actions  may  have  to  be  taken  to  ensure  that  lessons  learned  are  used 
appropriately. 


;  Examples  of  inappropriate  use  of  lessons  learned  include  the  following: 
i  •  Evaluating  the  performance  of  people  j 

J  ! 

•  Judging  process  performance  or  results 


Examples  of  ways  to  prevent  inappropriate  use  of  lessons  learned  include  the 
following: 

•  Controlling  access  to  the  lessons  learned 

•  Educating  people  about  the  appropriate  use  of  lessons  learned 


5.  Analyze  the  organization's  common  set  of  measures. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  measures. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  an  organizational 
measurement  repository,  including  common  measures. 

6.  Appraise  the  processes,  methods,  and  tools  in  use  in  the 
organization  and  develop  recommendations  for  improving  the 
organizational  process  assets. 
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This  appraisal  typically  includes  the  following: 

•  Determining  which  of  the  processes,  methods,  and  tools  are  of  potential  use  to 
other  parts  of  the  organization 

•  Appraising  the  quality  and  effectiveness  of  the  organizational  process  assets 

•  Identifying  candidate  improvements  to  the  organizational  process  assets 

•  Determining  compliance  with  the  organization’s  set  of  standard  processes  and 
tailoring  guidelines 

7.  Make  the  best  of  the  organization's  processes,  methods,  and  tools 
available  to  the  people  in  the  organization  as  appropriate. 

8.  Manage  process  improvement  proposals. 

Process  improvement  proposals  can  address  both  process  and  technology 
improvements. 

The  activities  for  managing  process  improvement  proposals  typically  include  the 
following: 

•  Soliciting  process  improvement  proposals 

•  Collecting  process  improvement  proposals 

•  Reviewing  process  improvement  proposals 

•  Selecting  the  process  improvement  proposals  that  will  be  implemented 

•  Tracking  the  implementation  of  process  improvement  proposals 

Process  improvement  proposals  are  documented  as  process  change  requests  or 
problem  reports,  as  appropriate. 

Some  process  improvement  proposals  may  be  incorporated  into  the 
organization’s  process  action  plans. 

9.  Establish  and  maintain  records  of  the  organization's  process 
improvement  activities. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 
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Continuous  Only 

GP  1.1 

Perform  Specific  Practices 

Perform  the  specific  practices  of  the  organizational  process 
focus  process  to  develop  work  products  and  provide  services 
to  achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  organizational  process  focus  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  determining 
process  improvement  opportunities  for  the  processes  being  used  and 
for  planning,  implementing,  and  deploying  process  improvements 
across  the  organization. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
organizational  process  focus  process. 


Elaboration: 

This  plan  for  performing  the  organizational  process  focus  process, 
which  is  often  called  “the  process  improvement  plan,”  differs  from  the 
process  action  plans  described  in  specific  practices  in  this  process 
area.  The  plan  called  for  in  this  generic  practice  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process 
area,  from  the  establishment  of  organizational  process  needs  all  the 
way  through  to  the  incorporation  of  process-related  experiences  into  the 
organizational  process  assets. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
process  focus  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools: 

•  Database  management  systems 

•  Process  improvement  tools 

•  Web  page  builders  and  browsers 

•  Groupware 

•  Quality-improvement  tools  (e.g.,  cause-and-effect  diagrams,  affinity  diagrams,  and 
Pareto  charts) 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  organizational  process  focus  process. 


Elaboration: 

Two  groups  are  typically  established  and  assigned  responsibility  for 
process  improvement:  (1)  a  management  steering  committee  for 
process  improvement  to  provide  senior  management  sponsorship,  and 
(2)  a  process  group  to  facilitate  and  manage  the  process  improvement 
activities. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
process  focus  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 

i  •  CMMI  and  other  process  improvement  reference  models 
i  •  Planning  and  managing  process  improvement 

i  •  Tools,  methods,  and  analysis  techniques 

i  •  Process  modeling 

i  •  Facilitation  techniques 

•  Change  management 
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GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  process 
focus  process  under  appropriate  levels  of  control. 

Elaboration: 

:  Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Process  improvement  proposals 

:  •  Organization’s  approved  process  action  plans 

:  •  Training  materials  for  deploying  organizational  process  assets 

:  •  Guidelines  for  deploying  the  organization’s  set  of  standard  processes  on  new 
j  projects 

•  Plans  for  the  organization’s  process  appraisals 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
organizational  process  focus  process  as  planned. 


Elaboration: 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Coordinating  and  collaborating  on  process  improvement  activities  with  process 
owners,  those  who  are  or  will  be  performing  the  process,  and  support 
organizations  (e.g.,  training  staff  and  quality  assurance  representatives) 

•  Establishing  the  organizational  process  needs  and  objectives 

•  Appraising  the  organization’s  processes 

•  Implementing  process  action  plans 

•  Coordinating  and  collaborating  on  the  execution  of  pilots  to  test  selected 
improvements 

•  Deploying  organizational  process  assets  and  changes  to  organizational  process 
assets 

•  Communicating  the  plans,  status,  activities,  and  results  related  to  planning, 
implementing,  and  deploying  process  improvements 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  process  focus  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 
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Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  process  improvement  proposals  submitted,  accepted,  or  implemented 

•  CMMI  maturity  level  or  capability  level 

•  Schedule  for  deployment  of  an  organizational  process  asset 

•  Percentage  of  projects  using  the  current  organization’s  set  of  standard  processes 
(or  tailored  version  of  same) 

•  Issue  trends  associated  with  implementing  the  organization’s  set  of  standard 
processes  (i.e.,  number  of  issues  identified  and  number  closed) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  process 
focus  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance. 

Elaboration: 

'  Examples  of  activities  reviewed  include  the  following: 

j  •  Determining  process  improvement  opportunities 

j  •  Planning  and  coordinating  process  improvement  activities 

;  •  Deploying  the  organization’s  set  of  standard  processes  on  projects  at  their  startup 

Examples  of  work  products  reviewed  include  the  following: 

:  •  Process  improvement  plans 

i  •  Process  action  plans 

i  •  Process  deployment  plans 

•  Plans  for  the  organization’s  process  appraisals 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
process  focus  process  with  higher  level  management  and 
resolve  issues. 


Elaboration: 

These  reviews  are  typically  in  the  form  of  a  briefing  presented  to  the 
management  steering  committee  by  the  process  group  and  the  process 
action  teams. 
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Examples  of  presentation  topics  include  the  following: 

•  Status  of  improvements  being  developed  by  process  action  teams 

•  Results  of  pilots 

•  Results  of  deployments 

•  Schedule  status  for  achieving  significant  milestones  (e.g.,  readiness  for  an 
appraisal,  or  progress  toward  achieving  a  targeted  organizational  maturity  level  or 
capability  level  profile) 


Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
organizational  process  focus  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  organizational  process  focus  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Criteria  used  for  prioritizing  candidate  process  improvements 

•  Appraisal  findings  that  address  strengths  and  weaknesses  of  the  organization's 
processes 

•  Status  of  improvement  activities  against  the  schedule 

•  Records  of  tailoring  the  organization’s  set  of  standard  processes  and  implementing 
them  on  identified  projects 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  process  focus  process,  which  address  quality 
and  process  performance,  based  on  customer  needs  and 
business  objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  process  focus 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  process 
focus  process  in  fulfilling  the  relevant  business  objectives  of 
the  organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  organizational  process  focus  process. 
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ORGANIZATIONAL  PROCESS  PERFORMANCE 

A  Process  Management  Process  Area  at  Maturity  Level  4 


Purpose 


The  purpose  of  Organizational  Process  Performance  (OPP)  is  to 
establish  and  maintain  a  quantitative  understanding  of  the  performance 
of  the  organization’s  set  of  standard  processes  in  support  of  quality  and 
process-performance  objectives,  and  to  provide  the  process- 
performance  data,  baselines,  and  models  to  quantitatively  manage  the 
organization’s  projects. 


Introductory  Notes 


Process  performance  is  a  measure  of  the  actual  results  achieved  by 
following  a  process.  Process  performance  is  characterized  by  process 
measures  (e.g.,  effort,  cycle  time,  and  defect  removal  effectiveness) 
and  product  measures  (e.g.,  reliability,  defect  density,  capacity, 
response  time,  and  cost). 

The  common  measures  for  the  organization  are  composed  of  process 
and  product  measures  that  can  be  used  to  summarize  the  actual 
performance  of  processes  in  individual  projects  in  the  organization.  The 
organizational  data  for  these  measures  are  analyzed  to  establish  a 
distribution  and  range  of  results,  which  characterize  the  expected 
performance  of  the  process  when  used  on  any  individual  project  in  the 
organization. 

In  this  process  area,  the  phrase  “quality  and  process-performance 
objectives”  covers  objectives  and  requirements  for  product  quality, 
service  quality,  and  process  performance.  As  indicated  above,  the  term 
“process  performance”  includes  quality;  however,  to  emphasize  the 
importance  of  quality,  the  phrase  “quality  and  process-performance 
objectives”  is  used  rather  than  just  “process-performance  objectives.” 

The  expected  process  performance  can  be  used  in  establishing  the 
project’s  quality  and  process-performance  objectives  and  can  be  used 
as  a  baseline  against  which  actual  project  performance  can  be 
compared.  This  information  is  used  to  quantitatively  manage  the 
project.  Each  quantitatively  managed  project,  in  turn,  provides  actual 
performance  results  that  become  a  part  of  the  baseline  data  for  the 
organizational  process  assets. 

The  associated  process-performance  models  are  used  to  represent 
past  and  current  process  performance  and  to  predict  future  results  of 
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the  process.  For  example,  the  latent  defects  in  the  delivered  product 
can  be  predicted  using  measurements  of  defects  identified  during 
product  verification  activities. 

When  the  organization  has  measures,  data,  and  analytical  techniques 
for  critical  process,  product,  and  service  characteristics,  it  is  able  to  do 
the  following: 

•  Determine  whether  processes  are  behaving  consistently  or  have 
stable  trends  (i.e.,  are  predictable) 

•  Identify  processes  where  the  performance  is  within  natural  bounds 
that  are  consistent  across  process  implementation  teams 

•  Establish  criteria  for  identifying  whether  a  process  or  subprocess 
should  be  statistically  managed,  and  determine  pertinent  measures 
and  analytical  techniques  to  be  used  in  such  management 

•  Identify  processes  that  show  unusual  (e.g.,  sporadic  or 
unpredictable)  behavior 

•  Identify  any  aspects  of  the  processes  that  can  be  improved  in  the 
organization’s  set  of  standard  processes 

•  Identify  the  implementation  of  a  process  which  performs  best 

Related  Process  Areas 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process-performance  baselines  and 
models. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  measures  and  collecting  and  analyzing 
data. 


Specific  Goal  and  Practice  Summary 


SG  1  Establish  Performance  Baselines  and  Models 
SP  1 .1  Select  Processes 

SP  1 .2  Establish  Process-Performance  Measures 

SP  1 .3  Establish  Quality  and  Process-Performance  Objectives 
SP  1 .4  Establish  Process-Performance  Baselines 

SP  1 .5  Establish  Process-Performance  Models 


262 


Organizational  Process  Performance  (OPP) 


CMMI  for  Development 
Version  1.2 

Specific  Practices  by  Goal 


SG  1  Establish  Performance  Baselines  and  Models 

Baselines  and  models,  which  characterize  the  expected  process 
performance  of  the  organization's  set  of  standard  processes,  are 
established  and  maintained. 

Prior  to  establishing  process-performance  baselines  and  models,  it  is 
necessary  to  determine  which  processes  are  suitable  to  be  measured 
(the  Select  Processes  specific  practice),  which  measures  are  useful  for 
determining  process  performance  (the  Establish  Process-Performance 
Measures  specific  practice),  and  the  quality  and  process-performance 
objectives  for  those  processes  (the  Establish  Quality  and  Process- 
Performance  Objectives  specific  practice).  These  specific  practices  are 
often  interrelated  and  may  need  to  be  performed  concurrently  to  select 
the  appropriate  processes,  measures,  and  quality  and  process- 
performance  objectives.  Often,  the  selection  of  one  process,  measure, 
or  objective  will  constrain  the  selection  of  the  others.  For  example,  if  a 
certain  process  is  selected,  the  measures  and  objectives  for  that 
process  may  be  constrained  by  the  process  itself. 


SP  1.1  Select  Processes 

Select  the  processes  or  subprocesses  in  the  organization's  set 
of  standard  processes  that  are  to  be  included  in  the 
organization's  process-performance  analyses. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  structure  of  the  organizational  process  assets. 

The  organization’s  set  of  standard  processes  consists  of  a  set  of 
standard  processes  that,  in  turn,  are  composed  of  subprocesses. 

Typically,  it  will  not  be  possible,  useful,  or  economically  justifiable  to 
apply  statistical  management  techniques  to  all  processes  or 
subprocesses  of  the  organization’s  set  of  standard  processes.  Selection 
of  the  processes  and/or  subprocesses  is  based  on  the  needs  and 
objectives  of  both  the  organization  and  projects. 


Examples  of  criteria  which  may  be  used  for  the  selection  of  a  process  or  subprocess  for 
organizational  analysis  include  the  following: 

•  The  relationship  of  the  subprocess  to  key  business  objectives 

•  Current  availability  of  valid  historical  data  relevant  to  the  subprocess 

•  The  current  degree  of  variability  of  this  data 

•  Subprocess  stability  (e.g.  stable  performance  in  comparable  instances) 

•  The  availability  of  corporate  or  commercial  information  that  can  be  used  to  build 
predictive  models 
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The  existence  of  project  data  that  indicates  the  process  or  subprocess 
has  been  or  can  be  stabilized  is  a  useful  criterion  for  selection  of  a 
process  or  subprocess. 

Typical  Work  Products 

1 .  List  of  processes  or  subprocesses  identified  for  process- 
performance  analyses 

SP  1.2  Establish  Process-Performance  Measures 

Establish  and  maintain  definitions  of  the  measures  that  are  to 
be  included  in  the  organization’s  process-performance 
analyses. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  selecting  measures. 

Typical  Work  Products 

1 .  Definitions  for  the  selected  measures  of  process  performance 
Subpractices 

1 .  Determine  which  of  the  organization’s  business  objectives  for 
quality  and  process  performance  need  to  be  addressed  by  the 
measures. 

2.  Select  measures  that  provide  appropriate  insight  into  the 
organization’s  quality  and  process  performance. 

The  Goal  Question  Metric  paradigm  is  an  approach  that  can  be  used  to  select 
measures  that  provide  insight  into  the  organization’s  business  objectives. 


Examples  of  criteria  used  to  select  measures  include  the  following: 

•  Relationship  of  the  measures  to  the  organization’s  business  objectives 

•  Coverage  that  the  measures  provide  over  the  entire  life  of  the  product  or  service 

•  Visibility  that  the  measures  provide  into  the  process  performance 

•  Availability  of  the  measures 

•  Extent  to  which  the  measures  are  objective 

•  Frequency  at  which  the  observations  of  the  measure  can  be  collected 

•  Extent  to  which  the  measures  are  controllable  by  changes  to  the  process  or 
subprocess 

•  Extent  to  which  the  measures  represent  the  users’  view  of  effective  process 
performance 


3.  Incorporate  the  selected  measures  into  the  organization’s  set  of 
common  measures. 
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Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  organizational  process  assets. 

4.  Revise  the  set  of  measures  as  necessary. 


SP  1.3  Establish  Quality  and  Process-Performance  Objectives 

Establish  and  maintain  quantitative  objectives  for  quality  and 
process  performance  for  the  organization. 


The  organization’s  quality  and  process-performance  objectives  should 
have  the  following  attributes: 

•  Based  on  the  organization’s  business  objectives 

•  Based  on  the  past  performance  of  projects 

•  Defined  to  gauge  process  performance  in  areas  such  as  product 
quality,  productivity,  cycle  time,  or  response  time 

•  Constrained  by  the  inherent  variability  or  natural  bounds  of  the 
selected  process  or  subprocess 

Typical  Work  Products 

1 .  Organization's  quality  and  process-performance  objectives 
Subpractices 

1 .  Review  the  organization’s  business  objectives  related  to  quality 
and  process  performance. 


Examples  of  business  objectives  include  the  following: 

•  Achieve  a  development  cycle  of  a  specified  duration  for  a  specified  release  of  a 
product 

•  Achieve  an  average  response  time  less  than  a  specified  duration  for  a  specified 
version  of  a  service 

•  Deliver  functionality  of  the  product  to  a  target  percentage  of  estimated  cost 

•  Decrease  the  cost  of  maintenance  of  the  products  by  a  specified  percent 


2.  Define  the  organization’s  quantitative  objectives  for  quality  and 
process  performance. 

Objectives  may  be  established  for  process  or  subprocess  measurements  (e.g., 
effort,  cycle  time,  and  defect  removal  effectiveness)  as  well  as  for  product 
measurements  (e.g.,  reliability  and  defect  density)  and  service  measurements 
(e.g.,  capacity  and  response  times)  where  appropriate. 
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Examples  of  quality  and  process-performance  objectives  include  the  following: 

•  Achieve  a  specified  productivity 

•  Deliver  work  products  with  no  more  than  a  specified  number  of  latent  defects 

•  Shorten  time  to  delivery  to  a  specified  percentage  of  the  process-performance 
baseline 

•  Reduce  the  total  lifecycle  cost  of  new  and  existing  products  by  a  percentage 

•  Deliver  a  percentage  of  the  specified  product  functionality 


3.  Define  the  priorities  of  the  organization’s  objectives  for  quality  and 
process  performance. 

4.  Review,  negotiate,  and  obtain  commitment  for  the  organization’s 
quality  and  process-performance  objectives  and  their  priorities  from 
the  relevant  stakeholders. 

5.  Revise  the  organization’s  quantitative  objectives  for  quality  and 
process  performance  as  necessary. 


Examples  of  when  the  organization’s  quantitative  objectives  for  quality  and 
process  performance  may  need  to  be  revised  include  the  following: 

•  When  the  organization’s  business  objectives  change 

•  When  the  organization’s  processes  change 

•  When  actual  quality  and  process  performance  differs  significantly  from  the 
objectives 


SP  1.4  Establish  Process-Performance  Baselines 

Establish  and  maintain  the  organization's  process-performance 
baselines. 


The  organization’s  process-performance  baselines  are  a  measurement 
of  performance  for  the  organization’s  set  of  standard  processes  at 
various  levels  of  detail,  as  appropriate.  The  processes  include  the 
following: 

•  Sequence  of  connected  processes 

•  Processes  that  cover  the  entire  life  of  the  project 

•  Processes  for  developing  individual  work  products 

There  may  be  several  process-performance  baselines  to  characterize 
performance  for  subgroups  of  the  organization. 
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Examples  of  criteria  used  to  categorize  subgroups  include  the  following: 

•  Product  line 

•  Line  of  business 

•  Application  domain 

•  Complexity 

•  Team  size 

•  Work  product  size 

•  Process  elements  from  the  organization’s  set  of  standard  processes 


Allowable  tailoring  of  the  organization’s  set  of  standard  processes  may 
significantly  affect  the  comparability  of  the  data  for  inclusion  in  process- 
performance  baselines.  The  effects  of  tailoring  should  be  considered  in 
establishing  baselines.  Depending  on  the  tailoring  allowed,  separate 
performance  baselines  may  exist  for  each  type  of  tailoring. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process-performance  baselines. 

Typical  Work  Products 

1 .  Baseline  data  on  the  organization’s  process  performance 
Subpractices 

1 .  Collect  measurements  from  the  organization’s  projects. 

The  process  or  subprocess  in  use  when  the  measurement  was  taken  is  recorded 
to  enable  appropriate  use  later. 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  collecting  and  analyzing  data. 

2.  Establish  and  maintain  the  organization’s  process-performance 
baselines  from  the  collected  measurements  and  analyses. 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

Process-performance  baselines  are  derived  by  analyzing  the  collected  measures 
to  establish  a  distribution  and  range  of  results  that  characterize  the  expected 
performance  for  selected  processes  or  subprocesses  when  used  on  any  individual 
project  in  the  organization. 

The  measurements  from  stable  subprocesses  from  projects  should  be  used;  other 
data  may  not  be  reliable. 


Organizational  Process  Performance  (OPP) 


267 


CMMI  for  Development 
Version  1.2 


3.  Review  and  get  agreement  with  relevant  stakeholders  about  the 
organization's  process-performance  baselines. 

4.  Make  the  organization's  process-performance  information  available 
across  the  organization  in  the  organization's  measurement 
repository. 

The  organization’s  process-performance  baselines  are  used  by  the  projects  to 
estimate  the  natural  bounds  for  process  performance. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  the  organization’s 
measurement  repository. 

5.  Compare  the  organization’s  process-performance  baselines  to  the 
associated  objectives. 

6.  Revise  the  organization’s  process-performance  baselines  as 
necessary. 


Examples  of  when  the  organization’s  process-performance  baselines  may  need  to  : 
be  revised  include  the  following:  j 

•  When  the  processes  change  j 

•  When  the  organization’s  results  change  i 

•  When  the  organization’s  needs  change 


SP  1.5  Establish  Process-Performance  Models 

Establish  and  maintain  the  process-performance  models  for  the 
organization’s  set  of  standard  processes. 


Process-performance  models  are  used  to  estimate  or  predict  the  value 
of  a  process-performance  measure  from  the  values  of  other  process, 
product,  and  service  measurements.  These  process-performance 
models  typically  use  process  and  product  measurements  collected 
throughout  the  life  of  the  project  to  estimate  progress  toward  achieving 
objectives  that  cannot  be  measured  until  later  in  the  project’s  life. 

The  process-performance  models  are  used  as  follows: 

•  The  organization  uses  them  for  estimating,  analyzing,  and 
predicting  the  process  performance  associated  with  the  processes 
in  the  organization’s  set  of  standard  processes. 

•  The  organization  uses  them  to  assess  the  (potential)  return  on 
investment  for  process  improvement  activities. 

•  Projects  use  them  for  estimating,  analyzing,  and  predicting  the 
process  performance  for  their  defined  processes. 

•  Projects  use  them  for  selecting  processes  or  subprocesses  for  use. 
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These  measures  and  models  are  defined  to  provide  insight  into,  and  to 
provide  the  ability  to  predict,  critical  process  and  product  characteristics 
that  are  relevant  to  business  value. 

Examples  of  areas  of  concern  to  projects  in  which  models  may  be  useful  include  the 
following: 

•  Schedule  and  cost 

•  Reliability 

•  Defect  identification  and  removal  rates 

•  Defect  removal  effectiveness 

•  Latent  defect  estimation 

•  Response  time 

•  Project  progress 

•  Combinations  of  these  areas 


:  Examples  of  process-performance  models  include  the  following: 
:  •  System  dynamics  models 

:  •  Reliability  growth  models 

;  •  Complexity  models 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 

information  about  the  use  of  process-performance  models. 

Typical  Work  Products 

1.  Process-performance  models 

Subpractices 

1.  Establish  the  process-performance  models  based  on  the 
organization’s  set  of  standard  processes  and  the  organization’s 
process-performance  baselines. 

2.  Calibrate  the  process-performance  models  based  on  the 
organization’s  past  results  and  current  needs. 

3.  Review  the  process-performance  models  and  get  agreement  with 
relevant  stakeholders. 

4.  Support  the  projects’  use  of  the  process-performance  models. 

5.  Revise  the  process-performance  models  as  necessary. 
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:  Examples  of  when  the  process-performance  models  may  need  to  be  revised 
:  include  the  following: 

|  •  When  the  processes  change 
:  •  When  the  organization’s  results  change 
•  When  the  organization’s  needs  change 


Generic  Practices  by  Goal 


The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 


GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  organizational  process 
performance  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  organizational  process  performance 
process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  process-performance  baselines  for  the  organization’s  set  of 
standard  processes. 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
organizational  process  performance  process. 

Elaboration: 

This  plan  for  performing  the  organizational  process  performance 
process  can  be  included  in  (or  referenced  by)  the  organization’s 
process  improvement  plan,  which  is  described  in  the  Organizational 
Process  Focus  process  area,  or  it  may  be  documented  in  a  separate 
plan  that  describes  only  the  plan  for  the  organizational  process 
performance  process. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
process  performance  process,  developing  the  work  products, 
and  providing  the  services  of  the  process. 


Elaboration: 

Special  expertise  in  statistics  and  statistical  process  control  may  be 
needed  to  establish  the  process-performance  baselines  for  the 
organization’s  set  of  standard  processes. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Database  management  systems 

•  System  dynamics  model 

•  Process  modeling  tools 

•  Statistical  analysis  packages 

•  Problem-tracking  packages 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  organizational  process  performance  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
process  performance  process  as  needed. 
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Elaboration: 

:  Examples  of  training  topics  include  the  following: 

I  •  Process  and  process  improvement  modeling 

I  •  Quantitative  and  statistical  methods  (e.g.,  estimating  models,  Pareto  analysis,  and 
control  charts) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  process 
performance  process  under  appropriate  levels  of  control. 

Elaboration: 

:  Examples  of  work  products  placed  under  control  include  the  following: 

|  •  Organization’s  quality  and  process-performance  objectives 
j  •  Definitions  of  the  selected  measures  of  process  performance 
•  Baseline  data  on  the  organization’s  process  performance 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
organizational  process  performance  process  as  planned. 


Elaboration: 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Establishing  the  organization’s  quality  and  process-performance  objectives  and 
their  priorities 

•  Reviewing  and  resolving  issues  on  the  organization’s  process-performance 
baselines 

•  Reviewing  and  resolving  issues  on  the  organization’s  process-performance  models 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  process  performance 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 
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Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Trends  in  the  organization’s  process  performance  with  respect  to  changes  in  work 
products  and  task  attributes  (e.g.,  size  growth,  effort,  schedule,  and  quality) 

•  Schedule  for  collecting  and  reviewing  measures  to  be  used  for  establishing  a 
process-performance  baseline 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  process 
performance  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

•  Establishing  process-performance  baselines  and  models 

:  Examples  of  work  products  reviewed  include  the  following: 

|  •  Process-performance  plans 

:  •  Organization’s  quality  and  process-performance  objectives 

•  Definitions  of  the  selected  measures  of  process  performance 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
process  performance  process  with  higher  level  management 
and  resolve  issues. 

Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
organizational  process  performance  process. 
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Collect  Improvement  Information 


GP3.2 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  organizational  process  performance  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Process-performance  baselines 

•  Percent  of  measurement  data  that  is  rejected  because  of  inconsistencies  with  the 
process-performance  measurement  definitions 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  process  performance  process,  which  address 
quality  and  process  performance,  based  on  customer  needs 
and  business  objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  process  performance 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  process 
performance  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  organizational  process  performance  process. 
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ORGANIZATIONAL  TRAINING 


A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Training  (OT)  is  to  develop  the  skills  and 
knowledge  of  people  so  they  can  perform  their  roles  effectively  and 
efficiently. 


Introductory  Notes 


Organizational  Training  includes  training  to  support  the  organization’s 
strategic  business  objectives  and  to  meet  the  tactical  training  needs  that 
are  common  across  projects  and  support  groups.  Specific  training 
needs  identified  by  individual  projects  and  support  groups  are  handled 
at  the  project  and  support  group  level  and  are  outside  the  scope  of 
Organizational  Training.  Project  and  support  groups  are  responsible  for 
identifying  and  addressing  their  specific  training  needs. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  specific  training  needs  identified  by  projects. 

An  organizational  training  program  involves  the  following: 

•  Identifying  the  training  needed  by  the  organization 

•  Obtaining  and  providing  training  to  address  those  needs 

•  Establishing  and  maintaining  training  capability 

•  Establishing  and  maintaining  training  records 

•  Assessing  training  effectiveness 

Effective  training  requires  assessment  of  needs,  planning,  instructional 
design,  and  appropriate  training  media  (e.g.,  workbooks  and  computer 
software),  as  well  as  a  repository  of  training  process  data.  As  an 
organizational  process,  the  main  components  of  training  include  a 
managed  training  development  program,  documented  plans,  personnel 
with  appropriate  mastery  of  specific  disciplines  and  other  areas  of 
knowledge,  and  mechanisms  for  measuring  the  effectiveness  of  the 
training  program. 

The  identification  of  process  training  needs  is  primarily  based  on  the 
skills  that  are  required  to  perform  the  organization’s  set  of  standard 
processes. 


Organizational  Training  (OT) 


275 


CMMI  for  Development 
Version  1.2 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  set  of  standard  processes. 

Certain  skills  may  be  effectively  and  efficiently  imparted  through 
vehicles  other  than  in-class  training  experiences  (e.g.,  informal 
mentoring).  Other  skills  require  more  formalized  training  vehicles,  such 
as  in  a  classroom,  by  Web-based  training,  through  guided  self-study,  or 
via  a  formalized  on-the-job  training  program.  The  formal  or  informal 
training  vehicles  employed  for  each  situation  should  be  based  on  an 
assessment  of  the  need  for  training  and  the  performance  gap  to  be 
addressed.  The  term  “training”  used  throughout  this  process  area  is 
used  broadly  to  include  all  of  these  learning  options. 

Success  in  training  can  be  measured  in  terms  of  the  availability  of 
opportunities  to  acquire  the  skills  and  knowledge  needed  to  perform 
new  and  ongoing  enterprise  activities. 

Skills  and  knowledge  may  be  technical,  organizational,  or  contextual. 
Technical  skills  pertain  to  the  ability  to  use  the  equipment,  tools, 
materials,  data,  and  processes  required  by  a  project  or  a  process. 
Organizational  skills  pertain  to  behavior  within  and  according  to  the 
employee’s  organization  structure,  role  and  responsibilities,  and  general 
operating  principles  and  methods.  Contextual  skills  are  the  self¬ 
management,  communication,  and  interpersonal  abilities  needed  to 
successfully  perform  in  the  organizational  and  social  context  of  the 
project  and  support  groups. 

The  phrase  “project  and  support  groups”  is  used  frequently  in  the  text  of 
the  process  area  description  to  indicate  an  organization-level 
perspective. 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  process  assets. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  specific  training  needs  identified  by  projects. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  how  to 
apply  decision-making  criteria  when  determining  training  approaches. 
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Specific  Goal  and  Practice  Summary 

SG  1  Establish  an  Organizational  Training  Capability 
SP  1.1  Establish  the  Strategic  Training  Needs 

SP  1 .2  Determine  Which  T raining  Needs  Are  the  Responsibility  of  the  Organization 

SP  1.3  Establish  an  Organizational  Training  Tactical  Plan 
SP  1.4  Establish  Training  Capability 

SG  2  Provide  Necessary  Training 
SP2.1  Deliver  Training 

SP  2.2  Establish  Training  Records 

SP  2.3  Assess  Training  Effectiveness 


Specific  Practices  by  Goal 


SG  1  Establish  an  Organizational  Training  Capability 

A  training  capability,  which  supports  the  organization's  management  and 
technical  roles,  is  established  and  maintained. 

The  organization  identifies  the  training  required  to  develop  the  skills  and 
the  knowledge  necessary  to  perform  enterprise  activities.  Once  the 
needs  are  identified,  a  training  program  addressing  those  needs  is 
developed. 


IPPD  Addition 

Cross-functional  training,  leadership  training,  interpersonal  skills  training, 
and  training  in  the  skills  needed  to  integrate  appropriate  business  and 
technical  functions  is  needed  by  integrated  team  members.  The  potentially 
wider  range  of  requirements  and  participant  backgrounds  may  require 
relevant  stakeholders  who  were  not  involved  in  requirements  development 
to  take  cross  training  in  the  disciplines  involved  in  product  design  in  order  to 
commit  to  requirements  with  a  full  understanding  of  the  range  of 
requirements  and  their  interrelationships. 


SP  1.1  Establish  the  Strategic  Training  Needs 

Establish  and  maintain  the  strategic  training  needs  of  the 
organization. 


Strategic  training  needs  address  long-term  objectives  to  build  a 
capability  by  filling  significant  knowledge  gaps,  introducing  new 
technologies,  or  implementing  major  changes  in  behavior.  Strategic 
planning  typically  looks  two  to  five  years  into  the  future. 
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Examples  of  sources  of  strategic  training  needs  include  the  following: 

•  Organization’s  standard  processes 

•  Organization’s  strategic  business  plan 

•  Organization’s  process  improvement  plan 

•  Enterprise-level  initiatives 

•  Skill  assessments 

•  Risk  analyses 


IPPD  Addition 

IPPD  requires  leadership  and  interpersonal  skills  beyond  those  typically 
found  in  traditional  development  environments.  Specific  skills  emphasized 
in  an  IPPD  environment  include  the  following: 

•  The  ability  to  integrate  all  appropriate  business  and  technical  functions 
and  their  processes 

•  The  ability  to  coordinate  and  collaborate  with  others 


Typical  Work  Products 

1.  Training  needs 

2.  Assessment  analysis 
Subpractices 

1 .  Analyze  the  organization’s  strategic  business  objectives  and 
process  improvement  plan  to  identify  potential  future  training 
needs. 

2.  Document  the  strategic  training  needs  of  the  organization. 

.  Examples  of  categories  of  training  needs  include  (but  are  not  limited  to)  the 
i  following: 

i  •  Process  analysis  and  documentation 

:  •  Engineering  (e.g.,  requirements  analysis,  design,  testing,  configuration 
:  management,  and  quality  assurance) 

:  •  Service  delivery 

|  •  Selection  and  management  of  suppliers 
i  •  Management  (e.g.,  estimating,  tracking,  and  risk  management) 

:  •  Disaster  recovery  and  continuity  of  operations 

3.  Determine  the  roles  and  skills  needed  to  perform  the  organization’s 
set  of  standard  processes. 
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4.  Document  the  training  needed  to  perform  the  roles  in  the 
organization’s  set  of  standard  processes. 

5.  Document  the  training  needed  to  maintain  the  safe,  secure  and 
continued  operation  of  the  business. 

6.  Revise  the  organization’s  strategic  needs  and  required  training  as 
necessary. 


SP  1.2  Determine  Which  Training  Needs  Are  the  Responsibility  of  the 
Organization 

Determine  which  training  needs  are  the  responsibility  of  the 
organization  and  which  will  be  left  to  the  individual  project  or 
support  group. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
project-  and  support-group-specific  plans  for  training. 

In  addition  to  strategic  training  needs,  organizational  training  addresses 
training  requirements  that  are  common  across  projects  and  support 
groups.  Projects  and  support  groups  have  the  primary  responsibility  for 
identifying  and  addressing  their  specific  training  needs.  The 
organization’s  training  staff  is  only  responsible  for  addressing  common 
cross-project  and  support  group  training  needs  (e.g.,  training  in  work 
environments  common  to  multiple  projects).  In  some  cases,  however, 
the  organization’s  training  staff  may  address  additional  training  needs  of 
projects  and  support  groups,  as  negotiated  with  them,  within  the  context 
of  the  training  resources  available  and  the  organization’s  training 
priorities. 

Typical  Work  Products 

1 .  Common  project  and  support  group  training  needs 

2.  Training  commitments 

Subpractices 

1 .  Analyze  the  training  needs  identified  by  the  various  projects  and 
support  groups. 

Analysis  of  project  and  support  group  needs  is  intended  to  identify  common 
training  needs  that  can  be  most  efficiently  addressed  organization-wide.  These 
needs-analysis  activities  are  used  to  anticipate  future  training  needs  that  are  first 
visible  at  the  project  and  support  group  level. 

2.  Negotiate  with  the  various  projects  and  support  groups  on  how 
their  specific  training  needs  will  be  satisfied. 

The  support  provided  by  the  organization’s  training  staff  depends  on  the  training 
resources  available  and  the  organization’s  training  priorities. 
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:  Examples  of  training  appropriately  performed  by  the  project  or  support  group 
:  include  the  following: 

j  •  Training  in  the  application  or  service  domain  of  the  project 
:  •  Training  in  the  unique  tools  and  methods  used  by  the  project  or  support  group 
:  •  Training  in  safety,  security,  and  human  factors 


3.  Document  the  commitments  for  providing  training  support  to  the 
projects  and  support  groups. 


SP  1.3  Establish  an  Organizational  Training  Tactical  Plan 

Establish  and  maintain  an  organizational  training  tactical  plan. 


The  organizational  training  tactical  plan  is  the  plan  to  deliver  the  training 
that  is  the  responsibility  of  the  organization  and  is  necessary  for 
individuals  to  perform  their  roles  effectively.  This  plan  addresses  the 
near-term  execution  of  training  and  is  adjusted  periodically  in  response 
to  changes  (e.g.,  in  needs  or  resources)  and  to  evaluations  of 
effectiveness. 

Typical  Work  Products 

1 .  Organizational  training  tactical  plan 

Subpractices 

1.  Establish  plan  content. 

Organizational  training  tactical  plans  typically  contain  the  following: 

•  Training  needs 

•  Training  topics 

•  Schedules  based  on  training  activities  and  their  dependencies 

•  Methods  used  for  training 

•  Requirements  and  quality  standards  for  training  materials 

•  Training  tasks,  roles,  and  responsibilities 

•  Required  resources  including  tools,  facilities,  environments,  staffing,  and  skills  and 
knowledge 

2.  Establish  commitments  to  the  plan. 

Documented  commitments  by  those  responsible  for  implementing  and  supporting 
the  plan  are  essential  for  the  plan  to  be  effective. 

3.  Revise  plan  and  commitments  as  necessary. 
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SP  1.4  Establish  Training  Capability 

Establish  and  maintain  training  capability  to  address 
organizational  training  needs. 


Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  how  to 
apply  decision-making  criteria  when  selecting  training  approaches  and 
developing  training  materials. 

Typical  Work  Products 

1.  Training  materials  and  supporting  artifacts 
Subpractices 

1 .  Select  the  appropriate  approaches  to  satisfy  specific  organizational 
training  needs. 

Many  factors  may  affect  the  selection  of  training  approaches,  including  audience- 
specific  knowledge,  costs  and  schedule,  work  environment,  and  so  on.  Selection 
of  an  approach  requires  consideration  of  the  means  to  provide  skills  and 
knowledge  in  the  most  effective  way  possible  given  the  constraints. 

Examples  of  training  approaches  include  the  following: 

i  •  Classroom  training 
i  •  Computer-aided  instruction 
|  •  Guided  self-study 

:  •  Formal  apprenticeship  and  mentoring  programs 
i  •  Facilitated  videos 
|  •  Chalk  talks 
i  •  Brown-bag  lunch  seminars 
•  Structured  on-the-job  training 

2.  Determine  whether  to  develop  training  materials  internally  or 
acquire  them  externally. 

Determine  the  costs  and  benefits  of  internal  training  development  or  of  obtaining 
training  externally. 
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Example  criteria  that  can  be  used  to  determine  the  most  effective  mode  of 
knowledge  or  skill  acquisition  include  the  following: 

•  Performance  objectives 

•  Time  available  to  prepare  for  project  execution 

•  Business  objectives 

•  Availability  of  in-house  expertise 

•  Availability  of  training  from  external  sources 

Examples  of  external  sources  of  training  include  the  following: 

•  Customer-provided  training 

•  Commercially  available  training  courses 

•  Academic  programs 

•  Professional  conferences 

•  Seminars 


3.  Develop  or  obtain  training  materials. 

Training  may  be  provided  by  the  project,  by  support  groups,  by  the  organization, 
or  by  an  external  organization.  The  organization’s  training  staff  coordinates  the 
acquisition  and  delivery  of  training  regardless  of  its  source. 


Examples  of  training  materials  include  the  following: 

•  Courses 

•  Computer-aided  instruction 

•  Videos 


4.  Develop  or  obtain  qualified  instructors. 

To  ensure  that  internally  provided  training  instructors  have  the  necessary 
knowledge  and  training  skills,  criteria  can  be  defined  to  identify,  develop,  and 
qualify  them.  In  the  case  of  externally  provided  training,  the  organization’s  training 
staff  can  investigate  how  the  training  provider  determines  which  instructors  will 
deliver  the  training.  This  can  also  be  a  factor  in  selecting  or  continuing  to  use  a 
specific  training  provider. 

5.  Describe  the  training  in  the  organization's  training  curriculum. 
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;  Examples  of  the  information  provided  in  the  training  descriptions  for  each  course 
:  include  the  following: 

:•  Topics  covered  in  the  training 
|  •  Intended  audience 

:  •  Prerequisites  and  preparation  for  participating 
|  •  Training  objectives 
■  •  Length  of  the  training 
j  •  Lesson  plans 

j  •  Completion  criteria  for  the  course 
.  •  Criteria  for  granting  training  waivers 

6.  Revise  the  training  materials  and  supporting  artifacts  as  necessary. 


Examples  of  situations  in  which  the  training  materials  and  supporting  artifacts  may 
need  to  be  revised  include  the  following: 

•  Training  needs  change  (e.g.,  when  new  technology  associated  with  the  training 
topic  is  available) 

•  An  evaluation  of  the  training  identifies  the  need  for  change  (e.g.,  evaluations  of 
training  effectiveness  surveys,  training  program  performance  assessments,  or 
instructor  evaluation  forms) 


SG  2  Provide  Necessary  Training 

Training  necessary  for  individuals  to  perform  their  roles  effectively  is 
provided. 

In  selecting  people  to  be  trained,  the  following  should  be  taken  into 

consideration: 

•  Background  of  the  target  population  of  training  participants 

•  Prerequisite  background  to  receive  training 

•  Skills  and  abilities  needed  by  people  to  perform  their  roles 

•  Need  for  cross-discipline  technical  management  training  for  all 
disciplines,  including  project  management 

•  Need  for  managers  to  have  training  in  appropriate  organizational 
processes 

•  Need  for  training  in  the  basic  principles  of  all  appropriate  disciplines 
to  support  personnel  in  quality  management,  configuration 
management,  and  other  related  support  functions 

•  Need  to  provide  competency  development  for  critical  functional 
areas 

•  Need  to  maintain  the  competencies  and  qualifications  of  personnel 
to  operate  and  maintain  work  environments  common  to  multiple 
projects 
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SP  2.1  Deliver  Training 

Deliver  the  training  following  the  organizational  training  tactical 
plan. 


Typical  Work  Products 

1.  Delivered  training  course 

Subpractices 

1 .  Select  the  people  who  will  receive  the  training  necessary  to 
perform  their  roles  effectively. 

Training  is  intended  to  impart  knowledge  and  skills  to  people  performing  various 
roles  within  the  organization.  Some  people  already  possess  the  knowledge  and 
skills  required  to  perform  well  in  their  designated  roles.  Training  can  be  waived  for 
these  people,  but  care  should  be  taken  that  training  waivers  are  not  abused. 

2.  Schedule  the  training,  including  any  resources,  as  necessary  (e.g., 
facilities  and  instructors). 

Training  should  be  planned  and  scheduled.  Training  is  provided  that  has  a  direct 
bearing  on  the  expectations  of  work  performance.  Therefore,  optimal  training 
occurs  in  a  timely  manner  with  regard  to  imminent  job-performance  expectations. 
These  expectations  often  include  the  following: 

•  Training  in  the  use  of  specialized  tools 

•  Training  in  procedures  that  are  new  to  the  individual  who  will  perform  them 

3.  Conduct  the  training. 

Experienced  instructors  should  perform  training.  When  possible,  training  is 
conducted  in  settings  that  closely  resemble  actual  performance  conditions  and 
includes  activities  to  simulate  actual  work  situations.  This  approach  includes 
integration  of  tools,  methods,  and  procedures  for  competency  development. 
Training  is  tied  to  work  responsibilities  so  that  on-the-job  activities  or  other  outside 
experiences  will  reinforce  the  training  within  a  reasonable  time  after  the  training. 

4.  T rack  the  delivery  of  training  against  the  plan. 


SP  2.2  Establish  Training  Records 

Establish  and  maintain  records  of  the  organizational  training. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  information 
about  how  project  or  support  group  training  records  are  maintained. 

The  scope  of  this  practice  is  for  the  training  performed  at  the 
organizational  level.  Establishment  and  maintenance  of  training  records 
for  project-  or  support-group-sponsored  training  is  the  responsibility  of 
each  individual  project  or  support  group. 
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Typical  Work  Products 

1.  Training  records 

2.  Training  updates  to  the  organizational  repository 
Subpractices 

1 .  Keep  records  of  all  students  who  successfully  complete  each 
training  course  or  other  approved  training  activity  as  well  as  those 
who  are  unsuccessful. 

2.  Keep  records  of  all  staff  who  have  been  waived  from  specific 
training. 

The  rationale  for  granting  a  waiver  should  be  documented,  and  both  the  manager 
responsible  and  the  manager  of  the  excepted  individual  should  approve  the 
waiver  for  organizational  training. 

3.  Keep  records  of  all  students  who  successfully  complete  their 
designated  required  training. 

4.  Make  training  records  available  to  the  appropriate  people  for 
consideration  in  assignments. 

Training  records  may  be  part  of  a  skills  matrix  developed  by  the  training 
organization  to  provide  a  summary  of  the  experience  and  education  of  people,  as 
well  as  training  sponsored  by  the  organization. 


SP  2.3  Assess  Training  Effectiveness 

Assess  the  effectiveness  of  the  organization’s  training 
program. 

A  process  should  exist  to  determine  the  effectiveness  of  training  (i.e., 
how  well  the  training  is  meeting  the  organization’s  needs). 

Examples  of  methods  used  to  assess  training  effectiveness  include  the  following: 

;•  Testing  in  the  training  context 
I  •  Post-training  surveys  of  training  participants 
i  •  Surveys  of  managers’  satisfaction  with  post-training  effects 
•  Assessment  mechanisms  embedded  in  courseware 


Measures  may  be  taken  to  assess  the  benefit  of  the  training  against 
both  the  project’s  and  organization’s  objectives.  Particular  attention 
should  be  paid  to  the  need  for  various  training  methods,  such  as 
training  teams  as  integral  work  units.  When  used,  performance 
objectives  should  be  shared  with  course  participants,  and  should  be 
unambiguous,  observable,  and  verifiable.  The  results  of  the  training¬ 
effectiveness  assessment  should  be  used  to  revise  training  materials  as 
described  in  the  Establish  Training  Capability  specific  practice. 
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Typical  Work  Products 

1.  Training-effectiveness  surveys 

2.  Training  program  performance  assessments 

3.  Instructor  evaluation  forms 

4.  Training  examinations 

Subpractices 

1 .  Assess  in-progress  or  completed  projects  to  determine  whether 
staff  knowledge  is  adequate  for  performing  project  tasks. 

2.  Provide  a  mechanism  for  assessing  the  effectiveness  of  each 
training  course  with  respect  to  established  organizational,  project, 
or  individual  learning  (or  performance)  objectives. 

3.  Obtain  student  evaluations  of  how  well  training  activities  met  their 
needs. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  organizational  training 
process  to  develop  work  products  and  provide  services  to 
achieve  the  specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 
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Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  organizational  training  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  identifying  the 
strategic  training  needs  of  the  organization,  and  providing  that  training. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
organizational  training  process. 


Elaboration: 

This  plan  for  performing  the  organizational  training  process  differs  from 
the  tactical  plan  for  organizational  training  described  in  a  specific 
practice  in  this  process  area.  The  plan  called  for  in  this  generic  practice 
would  address  the  comprehensive  planning  for  all  of  the  specific 
practices  in  this  process  area,  from  the  establishment  of  strategic 
training  needs  all  the  way  through  to  the  assessment  of  the 
effectiveness  of  the  organizational  training  effort.  In  contrast,  the 
organizational  training  tactical  plan  called  for  in  the  specific  practice 
would  address  the  periodic  planning  for  the  delivery  of  individual 
training  offerings. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
training  process,  developing  the  work  products,  and  providing 
the  services  of  the  process. 
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Elaboration: 

Examples  of  people  (full  or  part  time,  internal  or  external),  and  skills  needed  include  the 
i  following:  : 

i  •  Subject-matter  experts  : 

i  •  Curriculum  designers  i 

:  •  Instructional  designers  : 

i  •  Instructors  i 

•  Training  administrators 


Special  facilities  may  be  required  for  training.  When  necessary,  the 
facilities  required  for  the  activities  in  the  Organizational  Training  process 
area  are  developed  or  purchased. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Instruments  for  analyzing  training  needs 

•  Workstations  to  be  used  for  training 

•  Instructional  design  tools 

•  Packages  for  developing  presentation  materials 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  organizational  training  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
training  process  as  needed. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.5 
and  the  Organizational  Training  process  area. 
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Examples  of  training  topics  include  the  following: 

•  Knowledge  and  skills  needs  analysis 

•  Instructional  design 

•  Instructional  techniques  (e.g.,  train  the  trainer) 

•  Refresher  training  on  subject  matter 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  training 
process  under  appropriate  levels  of  control. 

Elaboration: 

:  Examples  of  work  products  placed  under  control  include  the  following: 

j  •  Organizational  training  tactical  plan 
:•  Training  records 

j  •  Training  materials  and  supporting  artifacts 
•  Instructor  evaluation  forms 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
organizational  training  process  as  planned. 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following: 

j  •  Establishing  a  collaborative  environment  for  discussion  of  training  needs  and 
:  training  effectiveness  to  ensure  that  the  organization’s  training  needs  are  met 

i  •  Identifying  training  needs 

i  •  Reviewing  the  organizational  training  tactical  plan 

•  Assessing  training  effectiveness 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  training  process  against 
the  plan  for  performing  the  process  and  take  appropriate 
corrective  action. 
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Elaboration: 

Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
I  the  following: 

i  •  Number  of  training  courses  delivered  (e.g.,  planned  versus  actual) 
i  •  Post-training  evaluation  ratings 
:  •  Training  program  quality  survey  ratings 
i  •  Schedule  for  delivery  of  training 
•  Schedule  for  development  of  a  course 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  training 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

I  •  Identifying  training  needs  and  making  training  available 
:  •  Providing  necessary  training 

:  Examples  of  work  products  reviewed  include  the  following: 

|  •  Organizational  training  tactical  plan 
;  •  Training  materials  and  supporting  artifacts 
•  Instructor  evaluation  forms 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
training  process  with  higher  level  management  and  resolve 
issues. 

Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 
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GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
organizational  training  process. 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  organizational  training  process  to  support  the 
future  use  and  improvement  of  the  organization’s  processes 
and  process  assets. 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Results  of  training  effectiveness  surveys 

•  Training  program  performance  assessment  results 

•  Course  evaluations 

•  Training  requirements  from  an  advisory  group 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  training  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  training  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 
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Continuous  Only 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  training 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  organizational  training  process. 
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PRODUCT  INTEGRATION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Product  Integration  (PI)  is  to  assemble  the  product  from 
the  product  components,  ensure  that  the  product,  as  integrated, 
functions  properly,  and  deliver  the  product. 


Introductory  Notes 


This  process  area  addresses  the  integration  of  product  components  into 
more  complex  product  components  or  into  complete  products. 

The  scope  of  this  process  area  is  to  achieve  complete  product 
integration  through  progressive  assembly  of  product  components,  in 
one  stage  or  in  incremental  stages,  according  to  a  defined  integration 
sequence  and  procedures.  Throughout  the  process  areas,  where  we 
use  the  terms  product  and  product  component,  their  intended  meanings 
also  encompass  services  and  their  components. 

A  critical  aspect  of  product  integration  is  the  management  of  internal 
and  external  interfaces  of  the  products  and  product  components  to 
ensure  compatibility  among  the  interfaces.  Attention  should  be  paid  to 
interface  management  throughout  the  project. 

Product  integration  is  more  than  just  a  one-time  assembly  of  the 
product  components  at  the  conclusion  of  design  and  fabrication. 

Product  integration  can  be  conducted  incrementally,  using  an  iterative 
process  of  assembling  product  components,  evaluating  them,  and  then 
assembling  more  product  components.  This  process  may  begin  with 
analysis  and  simulations  (e.g.,  threads,  rapid  prototypes,  virtual 
prototypes,  and  physical  prototypes)  and  steadily  progress  through 
increasingly  more  realistic  incremental  functionality  until  the  final 
product  is  achieved.  In  each  successive  build,  prototypes  (virtual,  rapid, 
or  physical)  are  constructed,  evaluated,  improved,  and  reconstructed 
based  on  knowledge  gained  in  the  evaluation  process.  The  degree  of 
virtual  versus  physical  prototyping  required  depends  on  the  functionality 
of  the  design  tools,  the  complexity  of  the  product,  and  its  associated 
risk.  There  is  a  high  probability  that  the  product,  integrated  in  this 
manner,  will  pass  product  verification  and  validation.  For  some  products 
and  services,  the  last  integration  phase  will  occur  when  they  are 
deployed  at  the  intended  operational  site. 
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Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  identifying  interface  requirements. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
defining  the  interfaces  and  the  integration  environment  (when  the 
integration  environment  needs  to  be  developed). 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  the  interfaces,  the  integration  environment,  and  the 
progressively  assembled  product  components. 

Refer  to  the  Validation  process  area  for  more  information  about 
performing  validation  of  the  product  components  and  the  integrated 
product. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  risks  and  the  use  of  prototypes  in  risk  mitigation  for  both 
interface  compatibility  and  product  component  integration. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  for  selecting  the 
appropriate  integration  sequence  and  procedures  and  for  deciding 
whether  the  integration  environment  should  be  acquired  or  developed. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  managing  changes  to  interface  definitions  and  about 
the  distribution  of  information. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  acquiring  product  components  or  parts  of  the 
integration  environment. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Product  Integration 

SP  1.1  Determine  Integration  Sequence 

SP  1 .2  Establish  the  Product  Integration  Environment 

SP  1 .3  Establish  Product  Integration  Procedures  and  Criteria 

SG  2  Ensure  Interface  Compatibility 

SP  2.1  Review  Interface  Descriptions  for  Completeness 

SP  2.2  Manage  Interfaces 

SG  3  Assemble  Product  Components  and  Deliver  the  Product 

SP  3.1  Confirm  Readiness  of  Product  Components  for  Integration 

SP  3.2  Assemble  Product  Components 

SP  3.3  Evaluate  Assembled  Product  Components 

SP  3.4  Package  and  Deliver  the  Product  or  Product  Component 
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Specific  Practices  by  Goal 


SG  1  Prepare  for  Product  Integration 

Preparation  for  product  integration  is  conducted. 

Preparing  for  integration  of  product  components  involves  establishing 
and  maintaining  an  integration  sequence,  the  environment  for 
performing  the  integration,  and  integration  procedures.  The  specific 
practices  of  the  Prepare  for  Product  Integration  specific  goal  build  on 
each  other  in  the  following  way.  The  first  specific  practice  determines 
the  sequence  for  product  and  product  component  integration.  The 
second  determines  the  environment  that  will  be  used  to  carry  out  the 
product  and  product  component  integration.  The  third  develops 
procedures  and  criteria  for  product  and  product  component  integration. 
Preparation  for  integration  starts  early  in  the  project  and  the  integration 
sequence  is  developed  concurrently  with  the  practices  in  the  Technical 
Solution  process  area. 


SP  1.1  Determine  Integration  Sequence 

Determine  the  product  component  integration  sequence. 


The  product  components  that  are  integrated  may  include  those  that  are 
a  part  of  the  product  to  be  delivered  along  with  test  equipment,  test 
software,  or  other  integration  items  such  as  fixtures.  Once  you  have 
analyzed  alternative  test  and  assembly  integration  sequences,  select 
the  best  integration  sequence. 

The  product  integration  sequence  can  provide  for  incremental  assembly 
and  evaluation  of  product  components  that  provide  a  problem-free 
foundation  for  incorporation  of  other  product  components  as  they 
become  available,  or  for  prototypes  of  high-risk  product  components. 

The  integration  sequence  should  be  harmonized  with  the  selection  of 
solutions  and  the  design  of  product  and  product  components  in  the 
Technical  Solution  process  area. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  to  select  the 
appropriate  product  integration  sequence. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  handling  risks  associated  with  the  integration  sequence. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  transitioning  acquired  product  components  and  the 
need  for  handling  those  product  components  in  the  product  integration 
sequence. 
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Typical  Work  Products 

1.  Product  integration  sequence 

2.  Rationale  for  selecting  or  rejecting  integration  sequences 
Subpractices 

1 .  Identify  the  product  components  to  be  integrated. 

2.  Identify  the  verifications  to  be  performed  during  the  integration  of 
the  product  components. 

3.  Identify  alternative  product  component  integration  sequences. 

This  can  include  defining  the  specific  tools  and  test  equipment  to  support  the 
product  integration. 

4.  Select  the  best  integration  sequence. 

5.  Periodically  review  the  product  integration  sequence  and  revise  as 
needed. 

Assess  the  product  integration  sequence  to  ensure  that  variations  in  production 
and  delivery  schedules  have  not  had  an  adverse  impact  on  the  sequence  or 
compromised  the  factors  on  which  earlier  decisions  were  made. 

6.  Record  the  rationale  for  decisions  made  and  deferred. 


SP  1.2  Establish  the  Product  Integration  Environment 

Establish  and  maintain  the  environment  needed  to  support  the 
integration  of  the  product  components. 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
make-or-buy  decisions. 

The  environment  for  product  integration  can  either  be  acquired  or 
developed.  To  establish  an  environment,  requirements  for  the  purchase 
or  development  of  equipment,  software,  or  other  resources  will  need  to 
be  developed.  These  requirements  are  gathered  when  implementing 
the  processes  associated  with  the  Requirements  Development  process 
area.  The  product  integration  environment  may  include  the  reuse  of 
existing  organizational  resources.  The  decision  to  acquire  or  develop 
the  product  integration  environment  is  addressed  in  the  processes 
associated  with  the  Technical  Solution  process  area. 

The  environment  required  at  each  step  of  the  product  integration 
process  may  include  test  equipment,  simulators  (taking  the  place  of 
unavailable  product  components),  pieces  of  real  equipment,  and 
recording  devices. 
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2.  Support  documentation  for  the  product  integration  environment 
Subpractices 

1 .  Identify  the  requirements  for  the  product  integration  environment. 

2.  Identify  verification  criteria  and  procedures  for  the  product 
integration  environment. 

3.  Decide  whether  to  make  or  buy  the  needed  product  integration 
environment. 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  acquiring  parts  of  the  integration 
environment. 

4.  Develop  an  integration  environment  if  a  suitable  environment 
cannot  be  acquired. 

For  unprecedented,  complex  projects,  the  product  integration  environment  can  be 
a  major  development.  As  such,  it  would  involve  project  planning,  requirements 
development,  technical  solutions,  verification,  validation,  and  risk  management. 

5.  Maintain  the  product  integration  environment  throughout  the 
project. 

6.  Dispose  of  those  portions  of  the  environment  that  are  no  longer 
useful. 


SP  1.3  Establish  Product  Integration  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  integration 
of  the  product  components. 


Procedures  for  the  integration  of  the  product  components  can  include 
such  things  as  the  number  of  incremental  iterations  to  be  performed 
and  details  of  the  expected  tests  and  other  evaluations  to  be  carried  out 
at  each  stage. 

Criteria  can  indicate  the  readiness  of  a  product  component  for 
integration  or  its  acceptability. 

Procedures  and  criteria  for  product  integration  address  the  following: 

•  Level  of  testing  for  build  components 

•  Verification  of  interfaces 

•  Thresholds  of  performance  deviation 

•  Derived  requirements  for  the  assembly  and  its  external  interfaces 

•  Allowable  substitutions  of  components 

•  Testing  environment  parameters 

•  Limits  on  cost  of  testing 
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•  Quality/cost  tradeoffs  for  integration  operations 

•  Probability  of  proper  functioning 

•  Delivery  rate  and  its  variation 

•  Lead  time  from  order  to  delivery 

•  Personnel  availability 

•  Availability  of  the  integration  facility/line/environment 

Criteria  can  be  defined  for  how  the  product  components  are  to  be 
verified  and  the  functions  they  are  expected  to  have.  Criteria  can  be 
defined  for  how  the  assembled  product  components  and  final  integrated 
product  are  to  be  validated  and  delivered. 

Criteria  may  also  constrain  the  degree  of  simulation  permitted  for  a 
product  component  to  pass  a  test,  or  may  constrain  the  environment  to 
be  used  for  the  integration  test. 

Pertinent  parts  of  the  schedule  and  criteria  for  assembly  should  be 
shared  with  suppliers  of  work  products  to  reduce  the  occurrence  of 
delays  and  component  failure 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  communicating  with  suppliers 

Typical  Work  Products 

1.  Product  integration  procedures 

2.  Product  integration  criteria 
Subpractices 

1 .  Establish  and  maintain  product  integration  procedures  for  the 
product  components. 

2.  Establish  and  maintain  criteria  for  product  component  integration 
and  evaluation. 

3.  Establish  and  maintain  criteria  for  validation  and  delivery  of  the 
integrated  product. 


SG  2  Ensure  Interface  Compatibility 

The  product  component  interfaces,  both  internal  and  external,  are 
compatible. 

Many  product  integration  problems  arise  from  unknown  or  uncontrolled 
aspects  of  both  internal  and  external  interfaces.  Effective  management 
of  product  component  interface  requirements,  specifications,  and 
designs  helps  ensure  that  implemented  interfaces  will  be  complete  and 
compatible. 
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Review  Interface  Descriptions  for  Completeness 

Review  interface  descriptions  for  coverage  and  completeness. 


The  interfaces  should  include,  in  addition  to  product  component 

interfaces,  all  the  interfaces  with  the  product  integration  environment. 

Typical  Work  Products 

1 .  Categories  of  interfaces 

2.  List  of  interfaces  per  category 

3.  Mapping  of  the  interfaces  to  the  product  components  and  the 
product  integration  environment 

Subpractices 

1 .  Review  interface  data  for  completeness  and  ensure  complete 
coverage  of  all  interfaces. 

Consider  all  the  product  components  and  prepare  a  relationship  table.  Interfaces 
are  usually  classified  in  three  main  classes:  environmental,  physical,  and 
functional.  Typical  categories  for  these  classes  include  the  following:  mechanical, 
fluid,  sound,  electrical,  climatic,  electromagnetic,  thermal,  message,  and  the 
human-machine  or  human  interface. 


Examples  of  interfaces  (e.g.,  for  mechanical  or  electronic  components)  that  may 
j  be  classified  within  these  three  classes  include  the  following: 

|  •  Mechanical  interfaces  (e.g.,  weight  and  size,  center  of  gravity,  clearance  of  parts 

■  in  operation,  space  required  for  maintenance,  fixed  links,  mobile  links,  and  shocks 
|  and  vibrations  received  from  the  bearing  structure) 

|  •  Noise  interfaces  (e.g.,  noise  transmitted  by  the  structure,  noise  transmitted  in  the 
air,  and  acoustics) 

:  •  Climatic  interfaces  (e.g.,  temperature,  humidity,  pressure,  and  salinity) 

:  •  Thermal  interfaces  (e.g.,  heat  dissipation,  transmission  of  heat  to  the  bearing 
:  structure,  and  air  conditioning  characteristics) 

:  •  Fluid  interfaces  (e.g.,  fresh  water  inlet/outlet,  seawater  inlet/outlet  for  a 

naval/coastal  product,  air  conditioning,  compressed  air,  nitrogen,  fuel,  lubricating 
oil,  and  exhaust  gas  outlet) 

|  •  Electrical  interfaces  (e.g.,  power  supply  consumption  by  network  with  transients 

■  and  peak  values;  nonsensitive  control  signal  for  power  supply  and 
communications;  sensitive  signal  [e.g.,  analog  links];  disturbing  signal  [e.g., 
microwave];  and  grounding  signal  to  comply  with  the  TEMPEST  standard) 

|  •  Electromagnetic  interfaces  (e.g.,  magnetic  field,  radio  and  radar  links,  optical  band 
link  wave  guides,  and  coaxial  and  optical  fibers) 

;  •  Human-machine  interface  (e.g.,  audio  or  voice  synthesis,  audio  or  voice 
i  recognition,  display  [analog  dial,  television  screen,  or  liquid-crystal  display, 

;  indicators'  light-emitting  diodes],  and  manual  controls  [pedal,  joystick,  ball,  keys, 

;  push  buttons,  or  touch  screen]) 

:  •  Message  interfaces  (e.g.,  origination,  destination,  stimulus,  protocols,  and  data 
characteristics) 
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2.  Ensure  that  product  components  and  interfaces  are  marked  to 
ensure  easy  and  correct  connection  to  the  joining  product 
component. 

3.  Periodically  review  the  adequacy  of  interface  descriptions. 

Once  established,  the  interface  descriptions  must  be  periodically  reviewed  to 
ensure  there  is  no  deviation  between  the  existing  descriptions  and  the  products 
being  developed,  processed,  produced,  or  bought. 

The  interface  descriptions  for  product  components  should  be  reviewed  with 
relevant  stakeholders  to  avoid  misinterpretations,  reduce  delays,  and  prevent  the 
development  of  interfaces  that  do  not  work  properly. 

SP  2.2  Manage  Interfaces 

Manage  internal  and  external  interface  definitions,  designs,  and 
changes  for  products  and  product  components. 

Interface  requirements  drive  the  development  of  the  interfaces 
necessary  to  integrate  product  components.  Managing  product  and 
product  component  interfaces  starts  very  early  in  the  development  of 
the  product.  The  definitions  and  designs  for  interfaces  affect  not  only 
the  product  components  and  external  systems,  but  can  also  affect  the 
verification  and  validation  environments. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  requirements  for  interfaces. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
design  of  interfaces  between  product  components. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  the  changes  to  the  interface  requirements. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  distributing  changes  to  the  interface  descriptions 
(specifications)  so  that  everyone  can  know  the  current  state  of  the 
interfaces. 

Management  of  the  interfaces  includes  maintenance  of  the  consistency 
of  the  interfaces  throughout  the  life  of  the  product,  and  resolution  of 
conflict,  noncompliance,  and  change  issues.  The  management  of 
interfaces  between  products  acquired  from  suppliers  and  other  products 
or  product  components  is  critical  for  success  of  the  project. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  suppliers. 
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SG  3 


The  interfaces  should  include,  in  addition  to  product  component 

interfaces,  all  the  interfaces  with  the  environment  as  well  as  other 

environments  for  verification,  validation,  operations,  and  support. 

The  interface  changes  are  documented,  maintained,  and  readily 

accessible. 

Typical  Work  Products 

1 .  Table  of  relationships  among  the  product  components  and  the 
external  environment  (e.g.,  main  power  supply,  fastening  product, 
and  computer  bus  system) 

2.  Table  of  relationships  among  the  different  product  components 

3.  List  of  agreed-to  interfaces  defined  for  each  pair  of  product 
components,  when  applicable 

4.  Reports  from  the  interface  control  working  group  meetings 

5.  Action  items  for  updating  interfaces 

6.  Application  program  interface  (API) 

7.  Updated  interface  description  or  agreement 

Subpractices 

1 .  Ensure  the  compatibility  of  the  interfaces  throughout  the  life  of  the 
product. 

2.  Resolve  conflict,  noncompliance,  and  change  issues. 

3.  Maintain  a  repository  for  interface  data  accessible  to  project 
participants. 

A  common  accessible  repository  for  interface  data  provides  a  mechanism  to 
ensure  that  everyone  knows  where  the  current  interface  data  resides  and  can 
access  it  for  use. 


Assemble  Product  Components  and  Deliver  the  Product 

Verified  product  components  are  assembled  and  the  integrated,  verified, 

and  validated  product  is  delivered. 

Integration  of  product  components  proceeds  according  to  the  product 
integration  sequence  and  available  procedures.  Before  integration, 
each  product  component  should  be  confirmed  to  be  compliant  with  its 
interface  requirements.  Product  components  are  assembled  into  larger, 
more  complex  product  components.  These  assembled  product 
components  are  checked  for  correct  interoperation.  This  process 
continues  until  product  integration  is  complete.  If,  during  this  process, 
problems  are  identified,  the  problem  should  be  documented  and  a 
corrective  action  process  initiated. 
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Ensure  that  the  assembly  of  the  product  components  into  larger  and 
more  complex  product  components  is  conducted  according  to  the 
product  integration  sequence  and  available  procedures.  The  timely 
receipt  of  needed  product  components  and  the  involvement  of  the  right 
people  contribute  to  the  successful  integration  of  the  product 
components  that  compose  the  product. 


SP  3.1  Confirm  Readiness  of  Product  Components  for  Integration 

Confirm,  prior  to  assembly,  that  each  product  component 
required  to  assemble  the  product  has  been  properly  identified, 
functions  according  to  its  description,  and  that  the  product 
component  interfaces  comply  with  the  interface  descriptions. 


Refer  to  the  Verification  process  area  for  more  information  about 
verifying  product  components. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
unit  test  of  product  components. 

The  purpose  of  this  specific  practice  is  to  ensure  that  the  properly 
identified  product  component  that  meets  its  description  can  actually  be 
assembled  according  to  the  product  integration  sequence  and  available 
procedures.  The  product  components  are  checked  for  quantity,  obvious 
damage,  and  consistency  between  the  product  component  and 
interface  descriptions. 

Those  conducting  product  integration  are  ultimately  responsible  for 
checking  to  make  sure  everything  is  proper  with  the  product 
components  before  assembly. 

Typical  Work  Products 

1 .  Acceptance  documents  for  the  received  product  components 

2.  Delivery  receipts 

3.  Checked  packing  lists 

4.  Exception  reports 

5.  Waivers 

Subpractices 

1 .  T rack  the  status  of  all  product  components  as  soon  as  they 
become  available  for  integration. 

2.  Ensure  that  product  components  are  delivered  to  the  product 
integration  environment  in  accordance  with  the  product  integration 
sequence  and  available  procedures. 

3.  Confirm  the  receipt  of  each  properly  identified  product  component. 
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4.  Ensure  that  each  received  product  component  meets  its 
description. 

5.  Check  the  configuration  status  against  the  expected  configuration. 

6.  Perform  a  pre-check  (e.g.,  by  a  visual  inspection  and  using  basic 
measures)  of  all  the  physical  interfaces  before  connecting  product 
components  together. 


SP  3.2  Assemble  Product  Components 

Assemble  product  components  according  to  the  product 
integration  sequence  and  available  procedures. 


The  assembly  activities  of  this  specific  practice  and  the  evaluation 
activities  of  the  next  specific  practice  are  conducted  iteratively,  from  the 
initial  product  components,  through  the  interim  assemblies  of  product 
components,  to  the  product  as  a  whole. 

Typical  Work  Products 

1 .  Assembled  product  or  product  components 
Subpractices 

1 .  Ensure  the  readiness  of  the  product  integration  environment. 

2.  Ensure  that  the  assembly  sequence  is  properly  performed. 

Record  all  appropriate  information  (e.g.,  configuration  status,  serial  numbers  of 
the  product  components,  types,  and  calibration  date  of  the  meters). 

3.  Revise  the  product  integration  sequence  and  available  procedures 
as  appropriate. 

SP  3.3  Evaluate  Assembled  Product  Components 

Evaluate  assembled  product  components  for  interface 
compatibility. 


Refer  to  the  Verification  process  area  for  more  information  about 
verifying  assembled  product  components. 

Refer  to  the  Validation  process  area  for  more  information  about 
validating  assembled  product  components. 

This  evaluation  involves  examining  and  testing  assembled  product 
components  for  performance,  suitability,  or  readiness  using  the 
available  procedures  and  environment.  It  is  performed  as  appropriate 
for  different  stages  of  assembly  of  product  components  as  identified  in 
the  product  integration  sequence  and  available  procedures.  The 
product  integration  sequence  and  available  procedures  may  define  a 
more  refined  integration  and  evaluation  sequence  than  might  be 
envisioned  just  by  examining  the  product  architecture.  For  example,  if 
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an  assembly  of  product  components  is  composed  of  four  less  complex 
product  components,  the  integration  sequence  will  not  necessarily  call 
for  the  simultaneous  integration  and  evaluation  of  the  four  units  as  one. 
Rather,  the  four  less  complex  units  may  be  integrated  progressively, 
one  at  a  time,  with  an  evaluation  after  each  assembly  operation  prior  to 
realizing  the  more  complex  product  component  that  matched  the 
specification  in  the  product  architecture.  Alternatively,  the  product 
integration  sequence  and  available  procedures  could  have  determined 
that  only  a  final  evaluation  was  the  best  one  to  perform. 

Typical  Work  Products 

1 .  Exception  reports 

2.  Interface  evaluation  reports 

3.  Product  integration  summary  reports 

Subpractices 

1 .  Conduct  the  evaluation  of  assembled  product  components 
following  the  product  integration  sequence  and  available 
procedures. 

2.  Record  the  evaluation  results. 


;  Example  results  include  the  following: 

|  •  Any  adaptation  required  to  the  integration  procedure 
|  •  Any  change  to  the  product  configuration  (spare  parts,  new  release) 
:  •  Evaluation  procedure  deviations 


SP  3.4  Package  and  Deliver  the  Product  or  Product  Component 

Package  the  assembled  product  or  product  component  and 
deliver  it  to  the  appropriate  customer. 


Refer  to  the  Verification  process  area  for  more  information  about 
verifying  the  product  or  an  assembly  of  product  components  before 
packaging. 

Refer  to  the  Validation  process  area  for  more  information  about 
validating  the  product  or  an  assembly  of  product  components  before 
packaging. 
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The  packaging  requirements  for  some  products  can  be  addressed  in 
their  specifications  and  verification  criteria.  This  is  especially  important 
when  items  are  stored  and  transported  by  the  customer.  In  such  cases, 
there  may  be  a  spectrum  of  environmental  and  stress  conditions 
specified  for  the  package.  In  other  circumstances,  factors  such  as  the 
following  may  become  important: 

•  Economy  and  ease  of  transportation  (e.g.,  containerization) 

•  Accountability  (e.g.,  shrink  wrapping) 

•  Ease  and  safety  of  unpacking  (e.g.,  sharp  edges,  strength  of 
binding  methods,  childproofing,  environmental  friendliness  of 
packing  material,  and  weight) 

The  adjustment  required  to  fit  product  components  together  in  the 
factory  could  be  different  from  the  one  required  to  fit  product 
components  together  when  installed  on  the  operational  site.  In  that 
case,  the  product’s  logbook  for  the  customer  should  be  used  to  record 
such  specific  parameters. 

Typical  Work  Products 

1 .  Packaged  product  or  product  components 

2.  Delivery  documentation 

Subpractices 

1.  Review  the  requirements,  design,  product,  verification  results,  and 
documentation  to  ensure  that  issues  affecting  the  packaging  and 
delivery  of  the  product  are  identified  and  resolved. 

2.  Use  effective  methods  to  package  and  deliver  the  assembled 
product. 

For  Software  Engineering 

\  Examples  of  software  packaging  and  delivery  methods  include  the  following: 

:  •  Magnetic  tape 
i  •Diskettes 
j  •  Hardcopy  documents 
:  •  Compact  disks 

■  •  Other  electronic  distribution  such  as  the  Internet 


3.  Satisfy  the  applicable  requirements  and  standards  for  packaging 
and  delivering  the  product. 


Examples  of  requirements  and  standards  include  those  for  safety,  the 
environment,  security,  transportability,  and  disposal. 
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For  Software  Engineering 

Examples  of  requirements  and  standards  for  packaging  and  delivering  software 
include  the  following: 

•  Type  of  storage  and  delivery  media 

•  Custodians  of  the  master  and  backup  copies 

•  Required  documentation 

•  Copyrights 

•  License  provisions 

•  Security  of  the  software 


4.  Prepare  the  operational  site  for  installation  of  the  product. 

Preparing  the  operational  site  may  be  the  responsibility  of  the  customer  or  end 
users. 

5.  Deliver  the  product  and  related  documentation  and  confirm  receipt. 

6.  Install  the  product  at  the  operational  site  and  confirm  correct 
operation. 

Installing  the  product  may  be  the  responsibility  of  the  customer  or  the  end  users. 
In  some  circumstances,  very  little  may  need  to  be  done  to  confirm  correct 
operation.  In  other  circumstances,  final  verification  of  the  integrated  product 
occurs  at  the  operational  site. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  product  integration 
process  to  develop  work  products  and  provide  services  to 
achieve  the  specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 
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Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  product  integration  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  developing 
product  integration  sequences,  procedures,  and  an  environment; 
ensuring  interface  compatibility  among  product  components; 
assembling  the  product  components;  and  delivering  the  product  and 
product  components. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  product 
integration  process. 


Elaboration: 

This  plan  for  performing  the  product  integration  process  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process 
area,  from  the  preparation  for  product  integration  all  the  way  through  to 
the  delivery  of  the  final  product. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  product 
integration  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 


Elaboration: 

Product  component  interface  coordination  may  be  accomplished  with 
an  Interface  Control  Working  Group  consisting  of  people  who  represent 
external  and  internal  interfaces.  Such  groups  can  be  used  to  elicit 
needs  for  interface  requirements  development. 
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Special  facilities  may  be  required  for  assembling  and  delivering  the 
product.  When  necessary,  the  facilities  required  for  the  activities  in  the 
Product  Integration  process  area  are  developed  or  purchased. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Prototyping  tools 

•  Analysis  tools 

•  Simulation  tools 

•  Interface  management  tools 

•  Assembly  tools  (e.g.,  compilers,  make  files,  joining  tools,  jigs,  and  fixtures) 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  product  integration  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  product 
integration  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 
i  •  Application  domain 
i  •  Product  integration  procedures  and  criteria 
i  •  Organization’s  facilities  for  integration  and  assembly 
j  •  Assembly  methods 
•  Packaging  standards 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  product  integration 
process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Acceptance  documents  for  the  received  product  components 
I  •  Evaluated  assembled  product  and  product  components 
|  •  Product  integration  sequence 
j  •  Product  integration  procedures  and  criteria 
•  Updated  interface  description  or  agreement 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  product 
integration  process  as  planned. 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Reviewing  interface  descriptions  for  completeness 

•  Establishing  the  product  integration  sequence 

•  Establishing  the  product  integration  procedures  and  criteria 

•  Assembling  and  delivering  the  product  and  product  components 

•  Communicating  the  results  after  evaluation 

•  Communicating  new,  effective  product  integration  processes  to  give  affected 
people  the  opportunity  to  improve  their  performance 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  product  integration  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action. 
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Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 

the  following: 

•  Product  component  integration  profile  (e.g.,  product  component  assemblies 
planned  and  performed,  and  number  of  exceptions  found) 

•  Integration  evaluation  problem  report  trends  (e.g.,  number  written  and  number 
closed) 

•  Integration  evaluation  problem  report  aging  (i.e.,  how  long  each  problem  report  has 
been  open) 

•  Schedule  for  conduct  of  specific  integration  activities 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  product  integration 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance. 

Elaboration: 

;  Examples  of  activities  reviewed  include  the  following: 

i  •  Establishing  and  maintaining  a  product  integration  sequence 
i  •  Ensuring  interface  compatibility 
:  •  Assembling  product  components  and  delivering  the  product 

Examples  of  work  products  reviewed  include  the  following: 

:  •  Product  integration  sequence 
|  •  Product  integration  procedures  and  criteria 
i  •  Acceptance  documents  for  the  received  product  components 
•  Assembled  product  and  product  components 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  product 
integration  process  with  higher  level  management  and  resolve 
issues. 
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Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  product 
integration  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  product  integration  process  to  support  the 
future  use  and  improvement  of  the  organization’s  processes 
and  process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Records  of  the  receipt  of  product  components,  exception  reports,  confirmation  of 
configuration  status,  and  results  of  readiness  checking 

•  Percent  of  total  development  effort  spent  in  product  integration  (actual  to  date  plus 
estimate  to  complete) 

•  Defects  found  in  the  product  and  test  environment  during  product  integration 

•  Problem  reports  resulting  from  product  integration 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  product 
integration  process,  which  address  quality  and  process 
performance,  based  on  customer  needs  and  business 
objectives. 
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Continuous  Only 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  product  integration  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  product  integration 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  product  integration  process. 
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PROJECT  MONITORING  AND  CONTROL 

A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Project  Monitoring  and  Control  (PMC)  is  to  provide  an 
understanding  of  the  project’s  progress  so  that  appropriate  corrective 
actions  can  be  taken  when  the  project’s  performance  deviates 
significantly  from  the  plan. 


Introductory  Notes 


A  project’s  documented  plan  is  the  basis  for  monitoring  activities, 
communicating  status,  and  taking  corrective  action.  Progress  is 
primarily  determined  by  comparing  actual  work  product  and  task 
attributes,  effort,  cost,  and  schedule  to  the  plan  at  prescribed 
milestones  or  control  levels  within  the  project  schedule  or  work 
breakdown  structure  (WBS).  Appropriate  visibility  enables  timely 
corrective  action  to  be  taken  when  performance  deviates  significantly 
from  the  plan.  A  deviation  is  significant  if,  when  left  unresolved,  it 
precludes  the  project  from  meeting  its  objectives. 

The  term  “project  plan”  is  used  throughout  these  practices  to  refer  to  the 
overall  plan  for  controlling  the  project. 

When  actual  status  deviates  significantly  from  the  expected  values, 
corrective  actions  are  taken  as  appropriate.  These  actions  may  require 
replanning,  which  may  include  revising  the  original  plan,  establishing 
new  agreements,  or  including  additional  mitigation  activities  within  the 
current  plan. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  project  plan,  including  how  it  specifies  the  appropriate  level  of 
project  monitoring,  the  measures  used  to  monitor  progress,  and  known 
risks. 

Refer  to  the  Measurement  and  Analysis  process  area  for  information 
about  the  process  of  measuring,  analyzing,  and  recording  information. 
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Specific  Goal  and  Practice  Summary 


SG  1  Monitor  Project  Against  Plan 

SP  1.1 

Monitor  Project  Planning  Parameters 

SP  1.2 

Monitor  Commitments 

SP  1.3 

Monitor  Project  Risks 

SP  1.4 

Monitor  Data  Management 

SP  1.5 

Monitor  Stakeholder  Involvement 

SP  1.6 

Conduct  Progress  Reviews 

SP  1.7 

Conduct  Milestone  Reviews 

SG  2  Manage  Corrective  Action  to  Closure 

SP  2.1 

Analyze  Issues 

SP  2.2 

Take  Corrective  Action 

SP  2.3 

Manage  Corrective  Action 

Specific  Practices  by  Goal 


SG  1  Monitor  Project  Against  Plan 

Actual  performance  and  progress  of  the  project  are  monitored  against  the 
project  plan. 


SP  1.1  Monitor  Project  Planning  Parameters 

Monitor  the  actual  values  of  the  project  planning  parameters 
against  the  project  plan. 


Project  planning  parameters  constitute  typical  indicators  of  project 
progress  and  performance  and  include  attributes  of  work  products  and 
tasks,  cost,  effort,  and  schedule.  Attributes  of  the  work  products  and 
tasks  include  such  items  as  size,  complexity,  weight,  form,  fit,  or 
function. 

Monitoring  typically  involves  measuring  the  actual  values  of  project 
planning  parameters,  comparing  actual  values  to  the  estimates  in  the 
plan,  and  identifying  significant  deviations.  Recording  actual  values  of 
the  project  planning  parameters  includes  recording  associated 
contextual  information  to  help  understand  the  measures.  An  analysis  of 
the  impact  that  significant  deviations  have  on  determining  what 
corrective  actions  to  take  is  handled  in  the  second  specific  goal  and  its 
specific  practices  in  this  process  area. 

Typical  Work  Products 

1 .  Records  of  project  performance 

2.  Records  of  significant  deviations 
Subpractices 

1 .  Monitor  progress  against  the  schedule. 
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Progress  monitoring  typically  includes  the  following: 

•  Periodically  measuring  the  actual  completion  of  activities  and  milestones 

•  Comparing  actual  completion  of  activities  and  milestones  against  the  schedule 
documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  schedule  estimates  in  the  project  plan 

2.  Monitor  the  project's  cost  and  expended  effort. 

Effort  and  cost  monitoring  typically  includes  the  following: 

•  Periodically  measuring  the  actual  effort  and  cost  expended  and  staff  assigned 

•  Comparing  actual  effort,  costs,  staffing,  and  training  to  the  estimates  and  budget 
documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  budget  in  the  project  plan 

3.  Monitor  the  attributes  of  the  work  products  and  tasks. 

Refer  to  the  Project  Planning  process  area  for  information  about 
the  attributes  of  work  products  and  tasks. 

Monitoring  the  attributes  of  the  work  products  and  tasks  typically  includes  the 
following: 

•  Periodically  measuring  the  actual  attributes  of  the  work  products  and  tasks,  such 
as  size  or  complexity  (and  the  changes  to  the  attributes) 

•  Comparing  the  actual  attributes  of  the  work  products  and  tasks  (and  the  changes 
to  the  attributes)  to  the  estimates  documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  estimates  in  the  project  plan 

4.  Monitor  resources  provided  and  used. 

Refer  to  the  Project  Planning  process  area  for  information  about 
planned  resources. 

Examples  of  resources  include  the  following: 
j  •  Physical  facilities 

:  •  Computers,  peripherals,  and  software  used  in  design,  manufacturing,  testing,  and 
operation 

i  •  Networks 

j  •  Security  environment 

j  •  Project  staff 

:  •  Processes 

5.  Monitor  the  knowledge  and  skills  of  project  personnel. 

Refer  to  the  Project  Planning  process  area  for  information  about 
planning  for  knowledge  and  skills  needed  to  perform  the  project. 
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Monitoring  the  knowledge  and  skills  of  the  project  personnel  typically  includes  the 
following: 

•  Periodically  measuring  the  acquisition  of  knowledge  and  skills  by  project 
personnel 

•  Comparing  actual  training  obtained  to  that  documented  in  the  project  plan 

•  Identifying  significant  deviations  from  estimates  in  the  project  plan 

6.  Document  the  significant  deviations  in  the  project  planning 
parameters. 

SP1.2  Monitor  Commitments 

Monitor  commitments  against  those  identified  in  the  project 
plan. 


Typical  Work  Products 

1 .  Records  of  commitment  reviews 

Subpractices 

1.  Regularly  review  commitments  (both  external  and  internal). 

2.  Identify  commitments  that  have  not  been  satisfied  or  that  are  at 
significant  risk  of  not  being  satisfied. 

3.  Document  the  results  of  the  commitment  reviews. 


SP  1.3  Monitor  Project  Risks 

Monitor  risks  against  those  identified  in  the  project  plan. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  project  risks. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
risk  management  activities. 

Typical  Work  Products 

1 .  Records  of  project  risk  monitoring 

Subpractices 

1 .  Periodically  review  the  documentation  of  the  risks  in  the  context  of 
the  project’s  current  status  and  circumstances. 

2.  Revise  the  documentation  of  the  risks,  as  additional  information 
becomes  available,  to  incorporate  changes. 

3.  Communicate  risk  status  to  relevant  stakeholders. 


Examples  of  risk  status  include  the  following: 
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SP  1.4  Monitor  Data  Management 

Monitor  the  management  of  project  data  against  the  project 
plan. 


Refer  to  the  Plan  for  Data  Management  specific  practice  in  the  Project 
Planning  process  area  for  more  information  about  identifying  the  types 
of  data  that  should  be  managed  and  how  to  plan  for  their  management. 

Once  the  plans  for  the  management  of  project  data  are  made,  the 
management  of  that  data  must  be  monitored  to  ensure  that  those  plans 
are  accomplished. 

Typical  Work  Products 

1 .  Records  of  data  management 

Subpractices 

1 .  Periodically  review  data  management  activities  against  their 
description  in  the  project  plan. 

2.  Identify  and  document  significant  issues  and  their  impacts. 

3.  Document  the  results  of  data  management  activity  reviews. 

SP  1.5  Monitor  Stakeholder  Involvement 

Monitor  stakeholder  involvement  against  the  project  plan. 


Refer  to  the  Plan  Stakeholder  Involvement  specific  practice  in  the 
Project  Planning  process  area  for  more  information  about  identifying 
relevant  stakeholders  and  planning  the  appropriate  involvement  with 
them. 

Once  the  stakeholders  are  identified  and  the  extent  of  their  involvement 
within  the  project  is  specified  in  project  planning,  that  involvement  must 
be  monitored  to  ensure  that  the  appropriate  interactions  are  occurring. 

Typical  Work  Products 

1 .  Records  of  stakeholder  involvement 

Subpractices 

1 .  Periodically  review  the  status  of  stakeholder  involvement. 

2.  Identify  and  document  significant  issues  and  their  impacts. 

3.  Document  the  results  of  the  stakeholder  involvement  status 
reviews. 
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SP  1.6  Conduct  Progress  Reviews 

Periodically  review  the  project's  progress,  performance,  and 
issues. 


Progress  reviews  are  reviews  on  the  project  to  keep  stakeholders 
informed.  These  project  reviews  can  be  informal  reviews  and  may  not 
be  specified  explicitly  in  the  project  plans. 

Typical  Work  Products 

1.  Documented  project  review  results 

Subpractices 

1 .  Regularly  communicate  status  on  assigned  activities  and  work 
products  to  relevant  stakeholders. 

Managers,  staff  members,  customers,  end  users,  suppliers,  and  other  relevant 
stakeholders  within  the  organization  are  included  in  the  reviews  as  appropriate. 

2.  Review  the  results  of  collecting  and  analyzing  measures  for 
controlling  the  project. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  process  for  measuring  and  analyzing  project 
performance  data. 

3.  Identify  and  document  significant  issues  and  deviations  from  the 
plan. 

4.  Document  change  requests  and  problems  identified  in  any  of  the 
work  products  and  processes. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  how  changes  are  managed. 

5.  Document  the  results  of  the  reviews. 

6.  Track  change  requests  and  problem  reports  to  closure. 


SP  1.7  Conduct  Milestone  Reviews 

Review  the  accomplishments  and  results  of  the  project  at 
selected  project  milestones. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
milestone  planning. 

Milestone  reviews  are  planned  during  project  planning  and  are  typically 
formal  reviews. 
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Typical  Work  Products 

1.  Documented  milestone  review  results 
Subpractices 

1 .  Conduct  reviews  at  meaningful  points  in  the  project’s  schedule, 
such  as  the  completion  of  selected  stages,  with  relevant 
stakeholders. 

Managers,  staff  members,  customers,  end  users,  suppliers,  and  other  relevant 
stakeholders  within  the  organization  are  included  in  the  milestone  reviews  as 
appropriate. 

2.  Review  the  commitments,  plan,  status,  and  risks  of  the  project. 

3.  Identify  and  document  significant  issues  and  their  impacts. 

4.  Document  the  results  of  the  review,  action  items,  and  decisions. 

5.  Track  action  items  to  closure. 


SG  2  Manage  Corrective  Action  to  Closure 

Corrective  actions  are  managed  to  closure  when  the  project's  performance 
or  results  deviate  significantly  from  the  plan. 


SP  2.1  Analyze  Issues 

Collect  and  analyze  the  issues  and  determine  the  corrective 
actions  necessary  to  address  the  issues. 


Typical  Work  Products 

1 .  List  of  issues  needing  corrective  actions 
Subpractices 

1.  Gather  issues  for  analysis. 

Issues  are  collected  from  reviews  and  the  execution  of  other  processes. 

;  Examples  of  issues  to  be  gathered  include  the  following: 

i  •  Issues  discovered  through  performing  verification  and  validation  activities 

|  •  Significant  deviations  in  the  project  planning  parameters  from  the  estimates  in  the 
|  project  plan 

:  •  Commitments  (either  internal  or  external)  that  have  not  been  satisfied 
i  •  Significant  changes  in  risk  status 
|  •  Data  access,  collection,  privacy,  or  security  issues 
•  Stakeholder  representation  or  involvement  issues 
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2.  Analyze  issues  to  determine  need  for  corrective  action. 

Refer  to  the  Project  Planning  process  area  for  information  about 
corrective  action  criteria. 

Corrective  action  is  required  when  the  issue,  if  left  unresolved,  may  prevent  the 
project  from  meeting  its  objectives. 

SP  2.2  Take  Corrective  Action 

Take  corrective  action  on  identified  issues. 


Typical  Work  Products 

1 .  Corrective  action  plan 

Subpractices 

1 .  Determine  and  document  the  appropriate  actions  needed  to 
address  the  identified  issues. 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  the  project  plan  when  replanning  is  needed. 

Examples  of  potential  actions  include  the  following: 

j  •  Modifying  the  statement  of  work 
:  •  Modifying  requirements 
i  •  Revising  estimates  and  plans 
j  •  Renegotiating  commitments 
j  •  Adding  resources 
:  •  Changing  processes 
•  Revising  project  risks 

2.  Review  and  get  agreement  with  relevant  stakeholders  on  the 
actions  to  be  taken. 

3.  Negotiate  changes  to  internal  and  external  commitments. 

SP  2.3  Manage  Corrective  Action 

Manage  corrective  actions  to  closure. 


Typical  Work  Products 

1 .  Corrective  action  results 
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Subpractices 

1 .  Monitor  corrective  actions  for  completion. 

2.  Analyze  results  of  corrective  actions  to  determine  the  effectiveness 
of  the  corrective  actions. 

3.  Determine  and  document  appropriate  actions  to  correct  deviations 
from  planned  results  for  corrective  actions. 

Lessons  learned  as  a  result  of  taking  corrective  action  can  be  inputs  to  planning 
and  risk  management  processes. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  project  monitoring  and 
control  process  to  develop  work  products  and  provide  services 
to  achieve  the  specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  project  monitoring  and  control  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  monitoring 
performance  against  the  project  plan  and  managing  corrective  action  to 
closure  when  actual  performance  or  results  deviate  significantly  from 
the  plan. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  project 
monitoring  and  control  process. 
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Elaboration: 

This  plan  for  performing  the  project  monitoring  and  control  process  can 
be  part  of  (or  referenced  by)  the  project  plan,  as  described  in  the 
Project  Planning  process  area. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  project 
monitoring  and  control  process,  developing  the  work  products, 
and  providing  the  services  of  the  process. 

Elaboration: 

Examples  of  resources  provided  include  the  following  tools: 

;  •  Cost  tracking  systems 
i  •  Effort  reporting  systems 
I  •  Action  item  tracking  systems 
•  Project  management  and  scheduling  programs 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  project  monitoring  and  control  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  project 
monitoring  and  control  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 

|  •  Monitoring  and  control  of  projects 

i  •  Risk  management 

•  Data  management 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  project  monitoring  and 
control  process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Project  schedules  with  status 
j  •  Project  measurement  data  and  analysis 
:  •  Earned  value  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  project 
monitoring  and  control  process  as  planned. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.7 
and  the  Monitor  Stakeholder  Involvement  practice  in  the  Project 
Monitoring  and  Control  process  area. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Assessing  the  project  against  the  plan 

•  Reviewing  commitments  and  resolving  issues 

•  Reviewing  project  risks 

•  Reviewing  data  management  activities 

•  Reviewing  project  progress 

•  Managing  corrective  actions  to  closure 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  project  monitoring  and  control  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.8 
and  the  Project  Monitoring  and  Control  process  area. 
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Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  open  and  closed  corrective  actions 

•  Schedule  with  status  for  monthly  financial  data  collection,  analysis,  and  reporting 

•  Number  and  types  of  reviews  performed 

•  Review  schedule  (planned  versus  actual  and  slipped  target  dates) 

•  Schedule  for  collection  and  analysis  of  monitoring  data 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  project  monitoring  and 
control  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

:  •  Monitoring  project  performance  against  the  project  plan 

•  Managing  corrective  actions  to  closure 

Examples  of  work  products  reviewed  include  the  following: 
i  •  Records  of  project  performance 

•  Project  review  results 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  project 
monitoring  and  control  process  with  higher  level  management 
and  resolve  issues. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 
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Continuous/Maturity  Levels  3  -  5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  project 
monitoring  and  control  process. 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  project  monitoring  and  control  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Records  of  significant  deviations 

•  Criteria  for  what  constitutes  a  deviation 

•  Corrective  action  results 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  project 
monitoring  and  control  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  project  monitoring  and  control 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 
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Continuous  Only 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  project  monitoring  and 
control  process  in  fulfilling  the  relevant  business  objectives  of 
the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  project  monitoring  and  control  process. 
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PROJECT  PLANNING 


A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Project  Planning  (PP)  is  to  establish  and  maintain  plans 
that  define  project  activities. 


Introductory  Notes 


The  Project  Planning  process  area  involves  the  following: 

•  Developing  the  project  plan 

•  Interacting  with  stakeholders  appropriately 

•  Getting  commitment  to  the  plan 

•  Maintaining  the  plan 

Planning  begins  with  requirements  that  define  the  product  and  project. 

Planning  includes  estimating  the  attributes  of  the  work  products  and 
tasks,  determining  the  resources  needed,  negotiating  commitments, 
producing  a  schedule,  and  identifying  and  analyzing  project  risks. 
Iterating  through  these  activities  may  be  necessary  to  establish  the 
project  plan.  The  project  plan  provides  the  basis  for  performing  and 
controlling  the  project’s  activities  that  address  the  commitments  with  the 
project’s  customer. 

The  project  plan  will  usually  need  to  be  revised  as  the  project 
progresses  to  address  changes  in  requirements  and  commitments, 
inaccurate  estimates,  corrective  actions,  and  process  changes.  Specific 
practices  describing  both  planning  and  replanning  are  contained  in  this 
process  area. 

The  term  “project  plan”  is  used  throughout  the  generic  and  specific 
practices  in  this  process  area  to  refer  to  the  overall  plan  for  controlling 
the  project. 
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Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  developing  requirements  that  define  the  product  and 
product  components.  Product  and  product  component  requirements 
and  changes  to  those  requirements  serve  as  a  basis  for  planning  and 
replanning. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements  needed  for  planning  and 
replanning. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  managing  risks. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
transforming  requirements  into  product  and  product  component 
solutions. 

Specific  Goal  and  Practice  Summary 

SG  1  Establish  Estimates 

SP  1 . 1  Estimate  the  Scope  of  the  Project 
SP  1.2  Establish  Estimates  of  Work  Product  and  Task  Attributes 
SP  1 .3  Define  Project  Lifecycle 
SP  1 .4  Determine  Estimates  of  Effort  and  Cost 
SG  2  Develop  a  Project  Plan 

SP  2.1  Establish  the  Budget  and  Schedule 
SP  2.2  Identify  Project  Risks 

SP  2.3  Plan  for  Data  Management 

SP  2.4  Plan  for  Project  Resources 

SP  2.5  Plan  for  Needed  Knowledge  and  Skills 
SP  2.6  Plan  Stakeholder  Involvement 

SP  2.7  Establish  the  Project  Plan 

SG  3  Obtain  Commitment  to  the  Plan 

SP  3.1  Review  Plans  That  Affect  the  Project 
SP  3.2  Reconcile  Work  and  Resource  Levels 
SP  3.3  Obtain  Plan  Commitment 


Specific  Practices  by  Goal 


SG  1  Establish  Estimates 

Estimates  of  project  planning  parameters  are  established  and  maintained. 

Project  planning  parameters  include  all  information  needed  by  the 
project  to  perform  the  necessary  planning,  organizing,  staffing, 
directing,  coordinating,  reporting,  and  budgeting. 
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Estimates  of  planning  parameters  should  have  a  sound  basis  to  instill 
confidence  that  any  plans  based  on  these  estimates  are  capable  of 
supporting  project  objectives. 

Factors  that  are  typically  considered  when  estimating  these  parameters 
include  the  following: 

•  Project  requirements,  including  the  product  requirements,  the 
requirements  imposed  by  the  organization,  the  requirements 
imposed  by  the  customer,  and  other  requirements  that  impact  the 
project 

•  Scope  of  the  project 

•  Identified  tasks  and  work  products 

•  Technical  approach 

•  Selected  project  lifecycle  model  (e.g.,  waterfall,  incremental,  or 
spiral) 

•  Attributes  of  the  work  products  and  tasks  (e.g.,  size  or  complexity) 

•  Schedule 

•  Models  or  historical  data  for  converting  the  attributes  of  the  work 
products  and  tasks  into  labor  hours  and  cost 

•  Methodology  (e.g.,  models,  data,  algorithms)  used  to  determine 
needed  material,  skills,  labor  hours,  and  cost 

Documentation  of  the  estimating  rationale  and  supporting  data  is 
needed  for  stakeholders’  review  and  commitment  to  the  plan  and  for 
maintenance  of  the  plan  as  the  project  progresses. 


SP  1.1  Estimate  the  Scope  of  the  Project 

Establish  a  top-level  work  breakdown  structure  (WBS)  to 
estimate  the  scope  of  the  project. 


The  WBS  evolves  with  the  project.  Initially  a  top-level  WBS  can  serve  to 
structure  the  initial  estimating.  The  development  of  a  WBS  divides  the 
overall  project  into  an  interconnected  set  of  manageable  components. 
Typically,  the  WBS  is  a  product  oriented  structure  that  provides  a 
scheme  for  identifying  and  organizing  the  logical  units  of  work  to  be 
managed,  which  are  called  “work  packages.”  The  WBS  provides  a 
reference  and  organizational  mechanism  for  assigning  effort,  schedule, 
and  responsibility  and  is  used  as  the  underlying  framework  to  plan, 
organize,  and  control  the  work  done  on  the  project.  Some  projects  use 
the  term  “contract  WBS”  to  refer  to  the  portion  of  the  WBS  placed  under 
contract  (possibly  the  entire  WBS).  Not  all  projects  have  a  contract 
WBS  (e.g.,  internally  funded  development). 
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2.  Work  package  descriptions 

3.  WBS 

Subpractices 

1 .  Develop  a  WBS  based  on  the  product  architecture. 

The  WBS  provides  a  scheme  for  organizing  the  project’s  work  around  the  product 
and  product  components  that  the  work  supports.  The  WBS  should  permit  the 
identification  of  the  following  items: 

•  Identified  risks  and  their  mitigation  tasks 

•  Tasks  for  deliverables  and  supporting  activities 

•  Tasks  for  skill  and  knowledge  acquisition 

•  Tasks  for  development  of  needed  support  plans,  such  as  configuration 
management,  quality  assurance,  and  verification  plans 

•  Tasks  for  integration  and  management  of  nondevelopmental  items 

2.  Identify  the  work  packages  in  sufficient  detail  to  specify  estimates 
of  project  tasks,  responsibilities,  and  schedule. 

The  top-level  WBS  is  intended  to  help  in  gauging  the  project  work  effort  in  terms 
of  tasks  and  organizational  roles  and  responsibilities.  The  amount  of  detail  in  the 
WBS  at  this  more  detailed  level  helps  in  developing  realistic  schedules,  thereby 
minimizing  the  need  for  management  reserve. 

3.  Identify  product  or  product  components  that  will  be  externally 
acquired. 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  acquiring  products  from  sources  external  to 
the  project. 

4.  Identify  work  products  that  will  be  reused. 


SP  1.2  Establish  Estimates  of  Work  Product  and  Task  Attributes 

Establish  and  maintain  estimates  of  the  attributes  of  the  work 
products  and  tasks. 


Size  is  the  primary  input  to  many  models  used  to  estimate  effort,  cost, 
and  schedule.  The  models  can  also  be  based  on  inputs  such  as 
connectivity,  complexity,  and  structure. 
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Examples  of  types  of  work  products  for  which  size  estimates  are  made  include  the 
:  following: 

|  •  Deliverable  and  nondeliverable  work  products 
|  •  Documents  and  files 

•  Operational  and  support  hardware,  firmware,  and  software 

:  Examples  of  size  measures  include  the  following: 

:  •  Number  of  functions 

:  •  Function  points 

:  •  Source  lines  of  code 

:  •  Number  of  classes  and  objects 

i  •  Number  of  requirements 
i  •  Number  and  complexity  of  interfaces 
i  •  Number  of  pages 

i  •  Number  of  inputs  and  outputs 
:•  Number  of  technical  risk  items 
j  •  Volume  of  data 

j  •  Number  of  logic  gates  for  integrated  circuits 

j  •  Number  of  parts  (e.g.,  printed  circuit  boards,  components,  and  mechanical  parts) 

:  •  Physical  constraints  (e.g.,  weight  and  volume) 


The  estimates  should  be  consistent  with  project  requirements  to 
determine  the  project’s  effort,  cost,  and  schedule.  A  relative  level  of 
difficulty  or  complexity  should  be  assigned  for  each  size  attribute. 

Typical  Work  Products 

1.  Technical  approach 

2.  Size  and  complexity  of  tasks  and  work  products 

3.  Estimating  models 

4.  Attribute  estimates 

Subpractices 

1 .  Determine  the  technical  approach  for  the  project. 

The  technical  approach  defines  a  top-level  strategy  for  development  of  the 
product.  It  includes  decisions  on  architectural  features,  such  as  distributed  or 
client/server;  state-of-the-art  or  established  technologies  to  be  applied,  such  as 
robotics,  composite  materials,  or  artificial  intelligence;  and  breadth  of  the 
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functionality  expected  in  the  final  products,  such  as  safety,  security,  and 
ergonomics. 

2.  Use  appropriate  methods  to  determine  the  attributes  of  the  work 
products  and  tasks  that  will  be  used  to  estimate  the  resource 
requirements. 

Methods  for  determining  size  and  complexity  should  be  based  on  validated 
models  or  historical  data. 

The  methods  for  determining  attributes  evolve  as  our  understanding  of  the 
relationship  of  product  characteristics  to  attributes  increases. 


Examples  of  current  methods  include  the  following: 

•  Number  of  logic  gates  for  integrated  circuit  design 

•  Lines  of  code  or  function  points  for  software 

•  Number/complexity  of  requirements  for  systems  engineering 

•  Number  of  square  feet  for  standard-specified  residential  homes 


3.  Estimate  the  attributes  of  the  work  products  and  tasks. 

SP  1.3  Define  Project  Lifecycle 

Define  the  project  lifecycle  phases  on  which  to  scope  the 
planning  effort. 


The  determination  of  a  project’s  lifecycle  phases  provides  for  planned 
periods  of  evaluation  and  decision  making.  These  are  normally  defined 
to  support  logical  decision  points  at  which  significant  commitments  are 
made  concerning  resources  and  technical  approach.  Such  points 
provide  planned  events  at  which  project  course  corrections  and 
determinations  of  future  scope  and  cost  can  be  made. 

The  project  lifecycle  phases  need  to  be  defined  depending  on  the  scope 
of  requirements,  the  estimates  for  project  resources,  and  the  nature  of 
the  project.  Larger  projects  may  contain  multiple  phases,  such  as 
concept  exploration,  development,  production,  operations,  and  disposal. 
Within  these  phases,  subphases  may  be  needed.  A  development  phase 
may  include  subphases  such  as  requirements  analysis,  design, 
fabrication,  integration,  and  verification.  The  determination  of  project 
phases  typically  includes  selection  and  refinement  of  one  or  more 
development  models  to  address  interdependencies  and  appropriate 
sequencing  of  the  activities  in  the  phases. 

Depending  on  the  strategy  for  development,  there  may  be  intermediate 
phases  for  the  creation  of  prototypes,  increments  of  capability,  or  spiral 
model  cycles. 
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Understanding  the  project  lifecycle  is  crucial  in  determining  the  scope  of 
the  planning  effort  and  the  timing  of  the  initial  planning,  as  well  as  the 
timing  and  criteria  (critical  milestones)  for  replanning. 

Typical  Work  Products 

1 .  Project  lifecycle  phases 

Determine  Estimates  of  Effort  and  Cost 

Estimate  the  project  effort  and  cost  for  the  work  products  and 
tasks  based  on  estimation  rationale. 


Estimates  of  effort  and  cost  are  generally  based  on  the  results  of 
analysis  using  models  or  historical  data  applied  to  size,  activities,  and 
other  planning  parameters.  Confidence  in  these  estimates  is  based  on 
the  rationale  for  the  selected  model  and  the  nature  of  the  data.  There 
may  be  occasions  when  the  available  historical  data  does  not  apply, 
such  as  where  efforts  are  unprecedented  or  where  the  type  of  task  does 
not  fit  available  models.  An  effort  is  unprecedented  (to  some  degree)  if 
a  similar  product  or  component  has  never  been  built.  An  effort  may  also 
be  unprecedented  if  the  development  group  has  never  built  such  a 
product  or  component. 

Unprecedented  efforts  are  more  risky,  require  more  research  to  develop 
reasonable  bases  of  estimate,  and  require  more  management  reserve. 
The  uniqueness  of  the  project  must  be  documented  when  using  these 
models  to  ensure  a  common  understanding  of  any  assumptions  made 
in  the  initial  planning  stages. 

Typical  Work  Products 

1 .  Estimation  rationale 

2.  Project  effort  estimates 

3.  Project  cost  estimates 

Subpractices 

1 .  Collect  the  models  or  historical  data  that  will  be  used  to  transform 
the  attributes  of  the  work  products  and  tasks  into  estimates  of  the 
labor  hours  and  cost. 

Many  parametric  models  have  been  developed  to  aid  in  estimating  cost  and 
schedule.  The  use  of  these  models  as  the  sole  source  of  estimation  is  not 
recommended  because  these  models  are  based  on  historical  project  data  that 
may  or  may  not  be  pertinent  to  your  project.  Multiple  models  and/or  methods  can 
be  used  to  ensure  a  high  level  of  confidence  in  the  estimate. 

Historical  data  include  the  cost,  effort,  and  schedule  data  from  previously 
executed  projects,  plus  appropriate  scaling  data  to  account  for  differing  sizes  and 
complexity. 
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2.  Include  supporting  infrastructure  needs  when  estimating  effort  and 
cost. 

The  supporting  infrastructure  includes  resources  needed  from  a  development  and 
sustainment  perspective  for  the  product. 

Consider  the  infrastructure  resource  needs  in  the  development  environment,  the 
test  environment,  the  production  environment,  the  target  environment,  or  any 
appropriate  combination  of  these  when  estimating  effort  and  cost. 

:  Examples  of  infrastructure  resources  include  the  following: 

:  •  Critical  computer  resources  (e.g.,  memory,  disk  and  network  capacity,  peripherals, 
communication  channels,  and  the  capacities  of  these) 

:  •  Engineering  environments  and  tools  (e.g.,  tools  for  prototyping,  assembly, 
i  computer-aided  design  [CAD],  and  simulation) 

:  •  Facilities,  machinery,  and  equipment  (e.g.,  test  benches  and  recording  devices) 

3.  Estimate  effort  and  cost  using  models  and/or  historical  data. 

Effort  and  cost  inputs  used  for  estimating  typically  include  the  following: 

•  Judgmental  estimates  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi 
Method) 

•  Risks,  including  the  extent  to  which  the  effort  is  unprecedented 

•  Critical  competencies  and  roles  needed  to  perform  the  work 

•  Product  and  product  component  requirements 

•  Technical  approach 

•  WBS 

•  Size  estimates  of  work  products  and  anticipated  changes 

•  Cost  of  externally  acquired  products 

•  Selected  project  lifecycle  model  and  processes 

•  Lifecycle  cost  estimates 

•  Capability  of  tools  provided  in  engineering  environment 

•  Skill  levels  of  managers  and  staff  needed  to  perform  the  work 

•  Knowledge,  skill,  and  training  needs 

•  Facilities  needed  (e.g.,  office  and  meeting  space  and  workstations) 

•  Engineering  facilities  needed 

•  Capability  of  manufacturing  process(es) 

•  Travel 

•  Level  of  security  required  for  tasks,  work  products,  hardware,  software,  personnel, 
and  work  environment 

•  Service  level  agreements  for  call  centers  and  warranty  work 

•  Direct  labor  and  overhead 
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SG  2  Develop  a  Project  Plan 

A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the 
project. 

A  project  plan  is  a  formal,  approved  document  used  to  manage  and 
control  the  execution  of  the  project.  It  is  based  on  the  project 
requirements  and  the  established  estimates. 

The  project  plan  should  consider  all  phases  of  the  project  lifecycle. 
Project  planning  should  ensure  that  all  plans  affecting  the  project  are 
consistent  with  the  overall  project  plan. 

SP  2.1  Establish  the  Budget  and  Schedule 

Establish  and  maintain  the  project’s  budget  and  schedule. 

The  project’s  budget  and  schedule  are  based  on  the  developed 
estimates  and  ensure  that  budget  allocation,  task  complexity,  and  task 
dependencies  are  appropriately  addressed. 

Event-driven,  resource-limited  schedules  have  proven  to  be  effective  in 
dealing  with  project  risk.  Identifying  accomplishments  to  be 
demonstrated  before  initiation  of  the  event  provides  some  flexibility  in 
the  timing  of  the  event,  a  common  understanding  of  what  is  expected,  a 
better  vision  of  the  state  of  the  project,  and  a  more  accurate  status  of 
the  project’s  tasks. 

Typical  Work  Products 

1.  Project  schedules 

2.  Schedule  dependencies 

3.  Project  budget 

Subpractices 

1 .  Identify  major  milestones. 

Milestones  are  often  imposed  to  ensure  completion  of  certain  deliverables  by  the 
milestone.  Milestones  can  be  event  based  or  calendar  based.  If  calendar  based, 
once  milestone  dates  have  been  agreed  on,  it  is  often  very  difficult  to  change 
them. 

2.  Identify  schedule  assumptions. 

When  schedules  are  initially  developed,  it  is  common  to  make  assumptions  about 
the  duration  of  certain  activities.  These  assumptions  are  frequently  made  on  items 
for  which  little  if  any  estimation  data  is  available.  Identifying  these  assumptions 
provides  insight  into  the  level  of  confidence  (uncertainties)  in  the  overall  schedule. 

3.  Identify  constraints. 
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Factors  that  limit  the  flexibility  of  management  options  need  to  be  identified  as 
early  as  possible.  The  examination  of  the  attributes  of  the  work  products  and 
tasks  often  will  bring  these  issues  to  the  surface.  Such  attributes  can  include  task 
duration,  resources,  inputs,  and  outputs. 

4.  Identify  task  dependencies. 

Typically,  the  tasks  for  a  project  can  be  accomplished  in  some  ordered  sequence 
that  will  minimize  the  duration  of  the  project.  This  involves  the  identification  of 
predecessor  and  successor  tasks  to  determine  the  optimal  ordering. 


Examples  of  tools  that  can  help  determine  an  optimal  ordering  of  task  activities 
include  the  following: 

•  Critical  Path  Method  (CPM) 

•  Program  Evaluation  and  Review  Technique  (PERT) 

•  Resource-limited  scheduling 


5.  Define  the  budget  and  schedule. 

Establishing  and  maintaining  the  project’s  budget  and  schedule  typically  includes 
the  following: 

•  Defining  the  committed  or  expected  availability  of  resources  and  facilities 

•  Determining  time  phasing  of  activities 

•  Determining  a  breakout  of  subordinate  schedules 

•  Defining  the  dependencies  between  the  activities  (predecessor  or  successor 
relationships) 

•  Defining  the  schedule  activities  and  milestones  to  support  accuracy  in  progress 
measurement 

•  Identifying  milestones  for  delivery  of  products  to  the  customer 

•  Defining  activities  of  appropriate  duration 

•  Defining  milestones  of  appropriate  time  separation 

•  Defining  a  management  reserve  based  on  the  confidence  level  in  meeting  the 
schedule  and  budget 

•  Using  appropriate  historical  data  to  verify  the  schedule 

•  Defining  incremental  funding  requirements 

•  Documenting  project  assumptions  and  rationale 

6.  Establish  corrective  action  criteria. 

Criteria  are  established  for  determining  what  constitutes  a  significant  deviation 
from  the  project  plan.  A  basis  for  gauging  issues  and  problems  is  necessary  to 
determine  when  a  corrective  action  should  be  taken.  The  corrective  actions  may 
require  replanning,  which  may  include  revising  the  original  plan,  establishing  new 
agreements,  or  including  mitigation  activities  within  the  current  plan. 
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Identify  and  analyze  project  risks. 
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Refer  to  the  Risk  Management  process  area  for  more  information  about 
risk  management  activities. 

Refer  to  the  Monitor  Project  Risks  specific  practice  in  the  Project 
Monitoring  and  Control  process  area  for  more  information  about  risk 
monitoring  activities. 

Risks  are  identified  or  discovered  and  analyzed  to  support  project 
planning.  This  specific  practice  should  be  extended  to  all  the  plans  that 
affect  the  project  to  ensure  that  the  appropriate  interfacing  is  taking 
place  between  all  relevant  stakeholders  on  identified  risks.  Project 
planning  risk  identification  and  analysis  typically  include  the  following: 

•  Identifying  risks 

•  Analyzing  the  risks  to  determine  the  impact,  probability  of 
occurrence,  and  time  frame  in  which  problems  are  likely  to  occur 

•  Prioritizing  risks 

Typical  Work  Products 

1.  Identified  risks 

2.  Risk  impacts  and  probability  of  occurrence 

3.  Risk  priorities 

Subpractices 
1.  Identify  risks. 

The  identification  of  risks  involves  the  identification  of  potential  issues,  hazards, 
threats,  vulnerabilities,  and  so  on  that  could  negatively  affect  work  efforts  and 
plans.  Risks  must  be  identified  and  described  in  an  understandable  way  before 
they  can  be  analyzed.  When  identifying  risks,  it  is  a  good  idea  to  use  a  standard 
method  for  defining  risks.  Risk  identification  and  analysis  tools  can  be  used  to 
help  identify  possible  problems. 
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Examples  of  risk  identification  and  analysis  tools  include  the  following: 

:  •  Risk  taxonomies 
i  •  Risk  assessments 
|  •  Checklists 
:  •  Structured  interviews 
:  •  Brainstorming 
I  •  Performance  models 
|  •  Cost  models 
:  •  Network  analysis 

•  Quality  factor  analysis 

2.  Document  the  risks. 

3.  Review  and  obtain  agreement  with  relevant  stakeholders  on  the 
completeness  and  correctness  of  the  documented  risks. 

4.  Revise  the  risks  as  appropriate. 

Examples  of  when  identified  risks  may  need  to  be  revised  include  the  following: 

:  •  When  new  risks  are  identified 
i  •  When  risks  become  problems 
|  •  When  risks  are  retired 

•  When  project  circumstances  change  significantly 


SP  2.3  Plan  for  Data  Management 

Plan  for  the  management  of  project  data. 


IPPD  Addition 

When  integrated  teams  are  formed,  project  data  includes  data  developed 
and  used  solely  within  a  particular  team  as  well  as  data  applicable  across 
integrated  team  boundaries,  if  there  are  multiple  integrated  teams. 


Data  are  the  various  forms  of  documentation  required  to  support  a 
program  in  all  of  its  areas  (e.g.,  administration,  engineering, 
configuration  management,  finance,  logistics,  quality,  safety, 
manufacturing,  and  procurement).  The  data  can  take  any  form  (e.g., 
reports,  manuals,  notebooks,  charts,  drawings,  specifications,  files,  or 
correspondence).  The  data  may  exist  in  any  medium  (e.g.,  printed  or 
drawn  on  various  materials,  photographs,  electronic,  or  multimedia). 
Data  may  be  deliverable  (e.g.,  items  identified  by  a  program’s  contract 
data  requirements)  or  data  may  be  nondeliverable  (e.g.,  informal  data, 
trade  studies  and  analyses,  internal  meeting  minutes,  internal  design 


338 


Project  Planning  (PP) 


CMMI  for  Development 
Version  1.2 

review  documentation,  lessons  learned,  and  action  items).  Distribution 
can  take  many  forms,  including  electronic  transmission. 

The  data  requirements  for  the  project  should  be  established  for  both  the 
data  items  to  be  created  and  their  content  and  form,  based  on  a 
common  or  standard  set  of  data  requirements.  Uniform  content  and 
format  requirements  for  data  items  facilitate  understanding  of  data 
content  and  help  with  consistent  management  of  the  data  resources. 

The  reason  for  collecting  each  document  should  be  clear.  This  task 
includes  the  analysis  and  verification  of  project  deliverables  and 
nondeliverables,  contract  and  noncontract  data  requirements,  and 
customer-supplied  data.  Often,  data  is  collected  with  no  clear 
understanding  of  how  it  will  be  used.  Data  is  costly  and  should  be 
collected  only  when  needed. 

Typical  Work  Products 

1.  Data  management  plan 

2.  Master  list  of  managed  data 

3.  Data  content  and  format  description 

4.  Data  requirements  lists  for  acquirers  and  for  suppliers 

5.  Privacy  requirements 

6.  Security  requirements 

7.  Security  procedures 

8.  Mechanism  for  data  retrieval,  reproduction,  and  distribution 

9.  Schedule  for  collection  of  project  data 

10.  Listing  of  project  data  to  be  collected 

Subpractices 

1 .  Establish  requirements  and  procedures  to  ensure  privacy  and 
security  of  the  data. 

Not  everyone  will  have  the  need  or  clearance  necessary  to  access  the  project 
data.  Procedures  must  be  established  to  identify  who  has  access  to  what  data  as 
well  as  when  they  have  access  to  the  data. 

2.  Establish  a  mechanism  to  archive  data  and  to  access  archived 
data. 

Accessed  information  should  be  in  an  understandable  form  (e.g.,  electronic  or 
computer  output  from  a  database)  or  represented  as  originally  generated. 

3.  Determine  the  project  data  to  be  identified,  collected,  and 
distributed. 
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SP  2.4  Plan  for  Project  Resources 

Plan  for  necessary  resources  to  perform  the  project. 

IPPD  Addition 

When  integrated  teams  are  formed,  planning  for  project  resources  should 
consider  staffing  of  the  integrated  teams. 

Defining  project  resources  (labor,  machinery/equipment,  materials,  and 
methods)  and  quantities  needed  to  perform  project  activities  builds  on 
the  initial  estimates  and  provides  additional  information  that  can  be 
applied  to  expand  the  WBS  used  to  manage  the  project. 

The  top-level  WBS  developed  earlier  as  an  estimation  mechanism  is 
typically  expanded  by  decomposing  these  top  levels  into  work  packages 
that  represent  singular  work  units  that  can  be  separately  assigned, 
performed,  and  tracked.  This  subdivision  is  done  to  distribute 
management  responsibility  and  provide  better  management  control. 
Each  work  package  or  work  product  in  the  WBS  should  be  assigned  a 
unique  identifier  (e.g.,  number)  to  permit  tracking.  A  WBS  can  be  based 
on  requirements,  activities,  work  products,  or  a  combination  of  these 
items.  A  dictionary  that  describes  the  work  for  each  work  package  in  the 
WBS  should  accompany  the  work  breakdown  structure. 

Typical  Work  Products 

1 .  WBS  work  packages 

2.  WBS  task  dictionary 

3.  Staffing  requirements  based  on  project  size  and  scope 

4.  Critical  facilities/equipment  list 

5.  Process/workflow  definitions  and  diagrams 

6.  Program  administration  requirements  list 

Subpractices 

1.  Determine  process  requirements. 

The  processes  used  to  manage  a  project  must  be  identified,  defined,  and 
coordinated  with  all  the  relevant  stakeholders  to  ensure  efficient  operations  during 
project  execution. 

2.  Determine  staffing  requirements. 

The  staffing  of  a  project  depends  on  the  decomposition  of  the  project 
requirements  into  tasks,  roles,  and  responsibilities  for  accomplishing  the  project 
requirements  as  laid  out  within  the  work  packages  of  the  WBS. 
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Staffing  requirements  must  consider  the  knowledge  and  skills  required  for  each  of 
the  identified  positions,  as  defined  in  the  Plan  for  Needed  Knowledge  and  Skills 
specific  practice. 

3.  Determine  facilities,  equipment,  and  component  requirements. 

Most  projects  are  unique  in  some  sense  and  require  some  set  of  unique  assets  to 
accomplish  the  objectives  of  the  project.  The  determination  and  acquisition  of 
these  assets  in  a  timely  manner  are  crucial  to  project  success. 

Lead-time  items  need  to  be  identified  early  to  determine  how  they  will  be 
addressed.  Even  when  the  required  assets  are  not  unique,  compiling  a  list  of  all  of 
the  facilities,  equipment,  and  parts  (e.g.,  number  of  computers  for  the  personnel 
working  on  the  project,  software  applications,  and  office  space)  provides  insight 
into  aspects  of  the  scope  of  an  effort  that  are  often  overlooked. 

SP  2.5  Plan  for  Needed  Knowledge  and  Skills 

Plan  for  knowledge  and  skills  needed  to  perform  the  project. 


Refer  to  the  Organizational  Training  process  area  for  more  information 
about  knowledge  and  skills  information  to  be  incorporated  into  the 
project  plan. 

Knowledge  delivery  to  projects  involves  both  training  of  project 
personnel  and  acquisition  of  knowledge  from  outside  sources. 

Staffing  requirements  are  dependent  on  the  knowledge  and  skills 
available  to  support  the  execution  of  the  project. 

Typical  Work  Products 

1.  Inventory  of  skill  needs 

2.  Staffing  and  new  hire  plans 

3.  Databases  (e.g.,  skills  and  training) 

Subpractices 

1 .  Identify  the  knowledge  and  skills  needed  to  perform  the  project. 

2.  Assess  the  knowledge  and  skills  available. 

3.  Select  mechanisms  for  providing  needed  knowledge  and  skills. 


Example  mechanisms  include  the  following: 

•  In-house  training  (both  organizational  and  project) 

•  External  training 

•  Staffing  and  new  hires 

•  External  skill  acquisition 
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The  choice  of  in-house  training  or  outsourced  training  for  the  needed  knowledge 
and  skills  is  determined  by  the  availability  of  training  expertise,  the  project’s 
schedule,  and  the  business  objectives. 

4.  Incorporate  selected  mechanisms  into  the  project  plan. 


SP  2.6  Plan  Stakeholder  Involvement 

Plan  the  involvement  of  identified  stakeholders. 


IPPD  Addition 

When  integrated  teams  are  formed,  stakeholder  involvement  should  be 
planned  down  to  the  integrated  team  level. 


Stakeholders  are  identified  from  all  phases  of  the  project  lifecycle  by 
identifying  the  type  of  people  and  functions  needing  representation  in 
the  project  and  describing  their  relevance  and  the  degree  of  interaction 
for  specific  project  activities.  A  two-dimensional  matrix  with 
stakeholders  along  one  axis  and  project  activities  along  the  other  axis  is 
a  convenient  format  for  accomplishing  this  identification.  Relevance  of 
the  stakeholder  to  the  activity  in  a  particular  project  phase  and  the 
amount  of  interaction  expected  would  be  shown  at  the  intersection  of 
the  project  phase  activity  axis  and  the  stakeholder  axis. 

For  the  inputs  of  stakeholders  to  be  useful,  careful  selection  of  relevant 
stakeholders  is  necessary.  For  each  major  activity,  identify  the 
stakeholders  who  are  affected  by  the  activity  and  those  who  have 
expertise  that  is  needed  to  conduct  the  activity.  This  list  of  relevant 
stakeholders  will  probably  change  as  the  project  moves  through  the 
phases  of  the  project  lifecycle.  It  is  important,  however,  to  ensure  that 
relevant  stakeholders  in  the  latter  phases  of  the  lifecycle  have  early 
input  to  requirements  and  design  decisions  that  affect  them. 


Examples  of  the  type  of  material  that  should  be  included  in  a  plan  for  stakeholder 

interaction  include  the  following: 

•  List  of  all  relevant  stakeholders 

•  Rationale  for  stakeholder  involvement 

•  Roles  and  responsibilities  of  the  relevant  stakeholders  with  respect  to  the  project, 
by  project  lifecycle  phase 

•  Relationships  between  stakeholders 

•  Relative  importance  of  the  stakeholder  to  success  of  the  project,  by  project 
lifecycle  phase 

•  Resources  (e.g.,  training,  materials,  time,  and  funding)  needed  to  ensure 
stakeholder  interaction 

•  Schedule  for  phasing  of  stakeholder  interaction 
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Conduct  of  this  specific  practice  relies  on  shared  or  exchanged 
information  with  the  previous  Plan  for  Needed  Knowledge  and  Skills 
specific  practice. 

Typical  Work  Products 

1 .  Stakeholder  involvement  plan 

SP  2.7  Establish  the  Project  Plan 

Establish  and  maintain  the  overall  project  plan  content. 


A  documented  plan  that  addresses  all  relevant  planning  items  is 
necessary  to  achieve  the  mutual  understanding,  commitment,  and 
performance  of  individuals,  groups,  and  organizations  that  must 
execute  or  support  the  plans.  The  plan  generated  for  the  project  defines 
all  aspects  of  the  effort,  tying  together  in  a  logical  manner:  project 
lifecycle  considerations;  technical  and  management  tasks;  budgets  and 
schedules;  milestones;  data  management,  risk  identification,  resource 
and  skill  requirements;  and  stakeholder  identification  and  interaction. 
Infrastructure  descriptions  include  responsibility  and  authority 
relationships  for  project  staff,  management,  and  support  organizations. 

For  Software  Engineering 

For  software,  the  planning  document  is  often  referred  to  as  one  of  the 
following: 

•  Software  development  plan 

•  Software  project  plan 

•  Software  plan 


For  Flardware  Engineering 

For  hardware,  the  planning  document  is  often  referred  to  as  a  hardware 
development  plan.  Development  activities  in  preparation  for  production  may 
be  included  in  the  hardware  development  plan  or  defined  in  a  separate 
production  plan. 
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Examples  of  plans  that  have  been  used  in  the  U.S.  Department  of  Defense  community 

include  the  following: 

•  Integrated  Master  Plan— an  event-driven  plan  that  documents  significant 
accomplishments  with  pass/fail  criteria  for  both  business  and  technical  elements  of 
the  project  and  that  ties  each  accomplishment  to  a  key  program  event. 

•  Integrated  Master  Schedule— an  integrated  and  networked  multi-layered  schedule 
of  program  tasks  required  to  complete  the  work  effort  documented  in  a  related 
Integrated  Master  Plan. 

•  Systems  Engineering  Management  Plan— a  plan  that  details  the  integrated 
technical  effort  across  the  project. 

•  Systems  Engineering  Master  Schedule— an  event-based  schedule  that  contains  a 
compilation  of  key  technical  accomplishments,  each  with  measurable  criteria, 
requiring  successful  completion  to  pass  identified  events. 

•  Systems  Engineering  Detailed  Schedule— a  detailed,  time-dependent,  task- 
oriented  schedule  that  associates  specific  dates  and  milestones  with  the  Systems 
Engineering  Master  Schedule. 


Typical  Work  Products 
1 .  Overall  project  plan 


Obtain  Commitment  to  the  Plan 

Commitments  to  the  project  plan  are  established  and  maintained. 

To  be  effective,  plans  require  commitment  by  those  responsible  for 
implementing  and  supporting  the  plan. 


SP  3.1  Review  Plans  That  Affect  the  Project 

Review  all  plans  that  affect  the  project  to  understand  project 
commitments. 


IPPD  Addition 

When  integrated  teams  are  formed,  their  integrated  work  plans  are  among 
the  plans  to  review. 


Plans  developed  within  other  process  areas  will  typically  contain 
information  similar  to  that  called  for  in  the  overall  project  plan.  These 
plans  may  provide  additional  detailed  guidance  and  should  be 
compatible  with  and  support  the  overall  project  plan  to  indicate  who  has 
the  authority,  responsibility,  accountability,  and  control.  All  plans  that 
affect  the  project  should  be  reviewed  to  ensure  a  common 
understanding  of  the  scope,  objectives,  roles,  and  relationships  that  are 
required  for  the  project  to  be  successful.  Many  of  these  plans  are 
described  by  the  Plan  the  Process  generic  practice  in  each  of  the 
process  areas. 
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SP  3.2  Reconcile  Work  and  Resource  Levels 

Reconcile  the  project  plan  to  reflect  available  and  estimated 
resources. 


IPPD  Addition 

When  integrated  teams  are  formed,  special  attention  should  be  paid  to 
resource  commitments  in  circumstances  of  distributed  integrated  teams 
and  when  people  are  on  multiple  integrated  teams  in  one  or  more  projects. 


To  establish  a  project  that  is  feasible,  obtain  commitment  from  relevant 
stakeholders  and  reconcile  any  differences  between  the  estimates  and 
the  available  resources.  Reconciliation  is  typically  accomplished  by 
lowering  or  deferring  technical  performance  requirements,  negotiating 
more  resources,  finding  ways  to  increase  productivity,  outsourcing, 
adjusting  the  staff  skill  mix,  or  revising  all  plans  that  affect  the  project  or 
schedules. 

Typical  Work  Products 

1.  Revised  methods  and  corresponding  estimating  parameters  (e.g., 
better  tools  and  use  of  off-the-shelf  components) 

2.  Renegotiated  budgets 

3.  Revised  schedules 

4.  Revised  requirements  list 

5.  Renegotiated  stakeholder  agreements 


SP  3.3  Obtain  Plan  Commitment 

Obtain  commitment  from  relevant  stakeholders  responsible  for 
performing  and  supporting  plan  execution. 


IPPD  Addition 

When  integrated  teams  are  formed,  the  integrated  team  plans  should  have 
buy-in  from  the  team  members,  the  interfacing  teams,  the  project,  and  the 
process  owners  of  the  standard  processes  that  the  team  has  selected  for 
tailored  application. 


Obtaining  commitment  involves  interaction  among  all  relevant 
stakeholders  both  internal  and  external  to  the  project.  The  individual  or 
group  making  a  commitment  should  have  confidence  that  the  work  can 
be  performed  within  cost,  schedule,  and  performance  constraints. 
Often,  a  provisional  commitment  is  adequate  to  allow  the  effort  to  begin 
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and  to  permit  research  to  be  performed  to  increase  confidence  to  the 
appropriate  level  needed  to  obtain  a  full  commitment. 

Typical  Work  Products 

1 .  Documented  requests  for  commitments 

2.  Documented  commitments 

Subpractices 

1.  Identify  needed  support  and  negotiate  commitments  with  relevant 
stakeholders. 

The  WBS  can  be  used  as  a  checklist  for  ensuring  that  commitments  are  obtained 
for  all  tasks. 

The  plan  for  stakeholder  interaction  should  identify  all  parties  from  whom 
commitment  should  be  obtained. 

2.  Document  all  organizational  commitments,  both  full  and 
provisional,  ensuring  appropriate  level  of  signatories. 

Commitments  must  be  documented  to  ensure  a  consistent  mutual  understanding 
as  well  as  for  tracking  and  maintenance.  Provisional  commitments  should  be 
accompanied  by  a  description  of  the  risks  associated  with  the  relationship. 

3.  Review  internal  commitments  with  senior  management  as 
appropriate. 

4.  Review  external  commitments  with  senior  management  as 
appropriate. 

Management  may  have  the  necessary  insight  and  authority  to  reduce  risks 
associated  with  external  commitments. 

5.  Identify  commitments  on  interfaces  between  elements  in  the 
project,  and  with  other  projects  and  organizational  units  so  that 
they  can  be  monitored. 

Well-defined  interface  specifications  form  the  basis  for  commitments. 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  project  planning  process 
to  develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  project  planning  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  estimating  the 
planning  parameters,  making  internal  and  external  commitments,  and 
developing  the  plan  for  managing  the  project. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  project 
planning  process. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.2 
and  the  Project  Planning  process  area. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  project  planning 
process,  developing  the  work  products,  and  providing  the 
services  of  the  process. 
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Elaboration: 

Special  expertise,  equipment,  and  facilities  in  project  planning  may  be 
required.  Special  expertise  in  project  planning  may  include  the 
following: 

•  Experienced  estimators 

•  Schedulers 

•  Technical  experts  in  applicable  areas  (e.g.,  product  domain  and 
technology) 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Spreadsheet  programs 

•  Estimating  models 

•  Project  planning  and  scheduling  packages 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  project  planning  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  project  planning 
process  as  needed. 

Elaboration: 

;  Examples  of  training  topics  include  the  following: 

i  •  Estimating 

;  •  Budgeting 

I  •  Negotiating 

I  •  Risk  identification  and  analysis 

:  •  Data  management 
i  •  Planning 

•  Scheduling 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  project  planning 
process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Work  breakdown  structure 

I  •  Project  plan 

j  •  Data  management  plan 

•  Stakeholder  involvement  plan 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  project 
planning  process  as  planned. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.7 
and  the  Plan  Stakeholder  Involvement  practice  in  the  Project  Planning 
process  area. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Establishing  estimates 

•  Reviewing  and  resolving  issues  on  the  completeness  and  correctness  of  the 
project  risks 

•  Reviewing  data  management  plans 

•  Establishing  project  plans 

•  Reviewing  project  plans  and  resolving  issues  on  work  and  resource  issues 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  project  planning  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  revisions  to  the  plan 

•  Cost,  schedule,  and  effort  variance  per  plan  revision 

•  Schedule  for  development  and  maintenance  of  program  plans 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  project  planning  process 
against  its  process  description,  standards,  and  procedures, 
and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

I  •  Establishing  estimates 

;•  Developing  the  project  plan 

i 

•  Obtaining  commitments  to  the  project  plan 

:  Examples  of  work  products  reviewed  include  the  following: 

:  •  WBS 

:  •  Project  plan 

:  •  Data  management  plan 

:  •  Stakeholder  involvement  plan 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  project  planning 
process  with  higher  level  management  and  resolve  issues. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 


Continuous/Maturity  Levels  3  -  5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  project 
planning  process. 
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Continuous/Maturity  Levels  3  -  5  Only 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  project  planning  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and 
process  assets. 

Elaboration: 

Examples  of  work  products,  measures,  measurement  results,  and 
improvement  information  include  the  following: 

•  Project  data  library  structure 

•  Project  attribute  estimates 

•  Risk  impacts  and  probability  of  occurrence 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  project 
planning  process,  which  address  quality  and  process 
performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  project  planning  process  to  achieve 
the  established  quantitative  quality  and  process-performance 
objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  project  planning 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization. 
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PROCESS  AND  PRODUCT  QUALITY  ASSURANCE 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Process  and  Product  Quality  Assurance  (PPQA)  is  to 
provide  staff  and  management  with  objective  insight  into  processes  and 
associated  work  products. 


Introductory  Notes 


The  Process  and  Product  Quality  Assurance  process  area  involves  the 
following: 

•  Objectively  evaluating  performed  processes,  work  products,  and 
services  against  the  applicable  process  descriptions,  standards, 
and  procedures 

•  Identifying  and  documenting  noncompliance  issues 

•  Providing  feedback  to  project  staff  and  managers  on  the  results  of 
quality  assurance  activities 

•  Ensuring  that  noncompliance  issues  are  addressed 

The  Process  and  Product  Quality  Assurance  process  area  supports  the 
delivery  of  high-quality  products  and  services  by  providing  the  project 
staff  and  managers  at  all  levels  with  appropriate  visibility  into,  and 
feedback  on,  processes  and  associated  work  products  throughout  the 
life  of  the  project. 

The  practices  in  the  Process  and  Product  Quality  Assurance  process 
area  ensure  that  planned  processes  are  implemented,  while  the 
practices  in  the  Verification  process  area  ensure  that  the  specified 
requirements  are  satisfied.  These  two  process  areas  may  on  occasion 
address  the  same  work  product  but  from  different  perspectives.  Projects 
should  take  advantage  of  the  overlap  in  order  to  minimize  duplication  of 
effort  while  taking  care  to  maintain  the  separate  perspectives. 

Objectivity  in  process  and  product  quality  assurance  evaluations  is 
critical  to  the  success  of  the  project.  (See  the  definition  of  “objectively 
evaluate”  in  the  glossary.)  Objectivity  is  achieved  by  both  independence 
and  the  use  of  criteria.  A  combination  of  methods  providing  evaluations 
against  criteria  by  those  not  producing  the  work  product  is  often  used. 
Less  formal  methods  can  be  used  to  provide  broad  day-to-day 
coverage.  More  formal  methods  can  be  used  periodically  to  assure 
objectivity. 
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Examples  of  ways  to  perform  objective  evaluations  include  the  following: 

•  Formal  audits  by  organizationally  separate  quality  assurance  organizations 

•  Peer  reviews  which  may  be  performed  at  various  levels  of  formality 

•  In-depth  review  of  work  at  the  place  it  is  performed  (i.e.,  desk  audits) 

•  Distributed  review  and  comment  of  work  products 


Traditionally,  a  quality  assurance  group  that  is  independent  of  the 
project  provides  this  objectivity.  It  may  be  appropriate  in  some 
organizations,  however,  to  implement  the  process  and  product  quality 
assurance  role  without  that  kind  of  independence.  For  example,  in  an 
organization  with  an  open,  quality-oriented  culture,  the  process  and 
product  quality  assurance  role  may  be  performed,  partially  or 
completely,  by  peers;  and  the  quality  assurance  function  may  be 
embedded  in  the  process.  For  small  organizations,  this  might  be  the 
most  feasible  approach. 

If  quality  assurance  is  embedded  in  the  process,  several  issues  must  be 
addressed  to  ensure  objectivity.  Everyone  performing  quality  assurance 
activities  should  be  trained  in  quality  assurance.  Those  performing 
quality  assurance  activities  for  a  work  product  should  be  separate  from 
those  directly  involved  in  developing  or  maintaining  the  work  product. 

An  independent  reporting  channel  to  the  appropriate  level  of 
organizational  management  must  be  available  so  that  noncompliance 
issues  can  be  escalated  as  necessary. 


For  example,  in  implementing  peer  reviews  as  an  objective  evaluation  method: 

•  Members  are  trained  and  roles  are  assigned  for  people  attending  the  peer  reviews. 

•  A  member  of  the  peer  review  who  did  not  produce  this  work  product  is  assigned  to 
perform  the  role  of  QA. 

•  Checklists  are  available  to  support  the  QA  activity. 

•  Defects  are  recorded  as  part  of  the  peer  review  report  and  are  tracked  and 
escalated  outside  the  project  when  necessary. 


Quality  assurance  should  begin  in  the  early  phases  of  a  project  to 
establish  plans,  processes,  standards,  and  procedures  that  will  add 
value  to  the  project  and  satisfy  the  requirements  of  the  project  and  the 
organizational  policies.  Those  performing  quality  assurance  participate 
in  establishing  the  plans,  processes,  standards,  and  procedures  to 
ensure  that  they  fit  the  project’s  needs  and  that  they  will  be  useable  for 
performing  quality  assurance  evaluations.  In  addition,  the  specific 
processes  and  associated  work  products  that  will  be  evaluated  during 
the  project  are  designated.  This  designation  may  be  based  on  sampling 
or  on  objective  criteria  that  are  consistent  with  organizational  policies 
and  project  requirements  and  needs. 
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When  noncompliance  issues  are  identified,  they  are  first  addressed 
within  the  project  and  resolved  there  if  possible.  Any  noncompliance 
issues  that  cannot  be  resolved  within  the  project  are  escalated  to  an 
appropriate  level  of  management  for  resolution. 

This  process  area  applies  primarily  to  evaluations  of  the  activities  and 
work  products  of  a  project,  but  it  also  applies  to  evaluations  of 
nonproject  activities  and  work  products  such  as  training  activities.  For 
these  activities  and  work  products,  the  term  “project”  should  be 
appropriately  interpreted. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  processes  and  associated  work  products  that  will  be 
objectively  evaluated. 

Refer  to  the  Verification  process  area  for  more  information  about 
satisfying  specified  requirements. 

Specific  Goal  and  Practice  Summary 

SG  1  Objectively  Evaluate  Processes  and  Work  Products 
SP  1 .1  Objectively  Evaluate  Processes 
SP  1 .2  Objectively  Evaluate  Work  Products  and  Services 
SG  2  Provide  Objective  Insight 

SP  2.1  Communicate  and  Ensure  Resolution  of  Noncompliance  Issues 
SP  2.2  Establish  Records 


Specific  Practices  by  Goal 


SG  1  Objectively  Evaluate  Processes  and  Work  Products 

Adherence  of  the  performed  process  and  associated  work  products  and 
services  to  applicable  process  descriptions,  standards,  and  procedures  is 
objectively  evaluated. 


SP  1.1  Objectively  Evaluate  Processes 

Objectively  evaluate  the  designated  performed  processes 
against  the  applicable  process  descriptions,  standards,  and 
procedures. 


Objectivity  in  quality  assurance  evaluations  is  critical  to  the  success  of 
the  project.  A  description  of  the  quality  assurance  reporting  chain  and 
how  it  ensures  objectivity  should  be  defined. 

Typical  Work  Products 

1 .  Evaluation  reports 

2.  Noncompliance  reports 
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3.  Corrective  actions 


Subpractices 

1 .  Promote  an  environment  (created  as  part  of  project  management) 
that  encourages  employee  participation  in  identifying  and  reporting 
quality  issues. 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluations. 

The  intent  of  this  subpractice  is  to  provide  criteria,  based  on  business  needs,  such 
as  the  following: 

•  What  will  be  evaluated 

•  When  or  how  often  a  process  will  be  evaluated 

•  How  the  evaluation  will  be  conducted 

•  Who  must  be  involved  in  the  evaluation 

3.  Use  the  stated  criteria  to  evaluate  performed  processes  for 
adherence  to  process  descriptions,  standards,  and  procedures. 

4.  Identify  each  noncompliance  found  during  the  evaluation. 

5.  Identify  lessons  learned  that  could  improve  processes  for  future 
products  and  services. 


SP  1.2  Objectively  Evaluate  Work  Products  and  Services 

Objectively  evaluate  the  designated  work  products  and 
services  against  the  applicable  process  descriptions, 
standards,  and  procedures. 


Typical  Work  Products 

1 .  Evaluation  reports 

2.  Noncompliance  reports 

3.  Corrective  actions 

Subpractices 

1 .  Select  work  products  to  be  evaluated,  based  on  documented 
sampling  criteria  if  sampling  is  used. 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluation  of 
work  products. 
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The  intent  of  this  subpractice  is  to  provide  criteria,  based  on  business  needs,  such 
as  the  following: 

•  What  will  be  evaluated  during  the  evaluation  of  a  work  product 

•  When  or  how  often  a  work  product  will  be  evaluated 

•  How  the  evaluation  will  be  conducted 

•  Who  must  be  involved  in  the  evaluation 

3.  Use  the  stated  criteria  during  the  evaluations  of  work  products. 

4.  Evaluate  work  products  before  they  are  delivered  to  the  customer. 

5.  Evaluate  work  products  at  selected  milestones  in  their 
development. 

6.  Perform  in-progress  or  incremental  evaluations  of  work  products 
and  services  against  process  descriptions,  standards,  and 
procedures. 

7.  Identify  each  case  of  noncompliance  found  during  the  evaluations. 

8.  Identify  lessons  learned  that  could  improve  processes  for  future 
products  and  services. 


SG  2  Provide  Objective  Insight 

Noncompliance  issues  are  objectively  tracked  and  communicated,  and 
resolution  is  ensured. 


SP  2.1  Communicate  and  Ensure  Resolution  of  Noncompliance  Issues 

Communicate  quality  issues  and  ensure  resolution  of 
noncompliance  issues  with  the  staff  and  managers. 


Noncompliance  issues  are  problems  identified  in  evaluations  that  reflect 
a  lack  of  adherence  to  applicable  standards,  process  descriptions,  or 
procedures.  The  status  of  noncompliance  issues  provides  an  indication 
of  quality  trends.  Quality  issues  include  noncompliance  issues  and 
results  of  trend  analysis. 

When  local  resolution  of  noncompliance  issues  cannot  be  obtained,  use 
established  escalation  mechanisms  to  ensure  that  the  appropriate  level 
of  management  can  resolve  the  issue.  Track  noncompliance  issues  to 
resolution. 

Typical  Work  Products 

1 .  Corrective  action  reports 

2.  Evaluation  reports 

3.  Quality  trends 
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Subpractices 

1 .  Resolve  each  noncompliance  with  the  appropriate  members  of  the 
staff  where  possible. 

2.  Document  noncompliance  issues  when  they  cannot  be  resolved 
within  the  project. 


Examples  of  ways  to  resolve  noncompliance  within  the  project  include  the 
following: 

•  Fixing  the  noncompliance 

•  Changing  the  process  descriptions,  standards,  or  procedures  that  were  violated 

•  Obtaining  a  waiver  to  cover  the  noncompliance  issue 


3.  Escalate  noncompliance  issues  that  cannot  be  resolved  within  the 
project  to  the  appropriate  level  of  management  designated  to 
receive  and  act  on  noncompliance  issues. 

4.  Analyze  the  noncompliance  issues  to  see  if  there  are  any  quality 
trends  that  can  be  identified  and  addressed. 

5.  Ensure  that  relevant  stakeholders  are  aware  of  the  results  of 
evaluations  and  the  quality  trends  in  a  timely  manner. 

6.  Periodically  review  open  noncompliance  issues  and  trends  with  the 
manager  designated  to  receive  and  act  on  noncompliance  issues. 

7.  Track  noncompliance  issues  to  resolution. 


SP  2.2  Establish  Records 

Establish  and  maintain  records  of  the  quality  assurance 
activities. 


Typical  Work  Products 

1.  Evaluation  logs 

2.  Quality  assurance  reports 

3.  Status  reports  of  corrective  actions 

4.  Reports  of  quality  trends 

Subpractices 

1 .  Record  process  and  product  quality  assurance  activities  in 
sufficient  detail  such  that  status  and  results  are  known. 

2.  Revise  the  status  and  history  of  the  quality  assurance  activities  as 
necessary. 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  process  and  product 
quality  assurance  process  to  develop  work  products  and 
provide  services  to  achieve  the  specific  goals  of  the  process 
area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  process  and  product  quality  assurance 
process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  objectively 
evaluating  whether  processes  and  associated  work  products  adhere  to 
the  applicable  process  descriptions,  standards,  and  procedures;  and 
ensuring  that  noncompliance  is  addressed. 


This  policy  also  establishes  organizational  expectations  for  process  and 
product  quality  assurance  being  in  place  for  all  projects.  Process  and 
product  quality  assurance  must  possess  sufficient  independence  from 
project  management  to  provide  objectivity  in  identifying  and  reporting 
noncompliance  issues. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process  and 
product  quality  assurance  process. 


Elaboration: 

This  plan  for  performing  the  process  and  product  quality  assurance 
process  can  be  included  in  (or  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process  and 
product  quality  assurance  process,  developing  the  work 
products,  and  providing  the  services  of  the  process. 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools: 

•  Evaluation  tools 

•  Noncompliance  tracking  tool 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  process  and  product  quality  assurance  process. 


Elaboration: 

To  guard  against  subjectivity  or  bias,  ensure  that  those  people  assigned 
responsibility  and  authority  for  process  and  product  quality  assurance 
can  perform  their  evaluations  with  sufficient  independence  and 
objectivity. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  and 
product  quality  assurance  process  as  needed. 

Elaboration: 

:  Examples  of  training  topics  include  the  following: 

;  •  Application  domain 
:  •  Customer  relations 

:  •  Process  descriptions,  standards,  procedures,  and  methods  for  the  project 

:  •  Quality  assurance  objectives,  process  descriptions,  standards,  procedures, 
methods,  and  tools 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  process  and  product 
quality  assurance  process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Noncompliance  reports 

•  Evaluation  logs  and  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  process 
and  product  quality  assurance  process  as  planned. 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following: 

i  •  Establishing  criteria  for  the  objective  evaluations  of  processes  and  work  products 
i  •  Evaluating  processes  and  work  products 
i  •  Resolving  noncompliance  issues 
•  T racking  noncompliance  issues  to  closure 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  and  product  quality  assurance 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Variance  of  objective  process  evaluations  planned  and  performed 

•  Variance  of  objective  work  product  evaluations  planned  and  performed 

•  Schedule  for  objective  evaluations 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  and  product 
quality  assurance  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 


Elaboration: 

Refer  to  Table  6.2  on  page  95  in  Generic  Goals  and  Generic  Practices 
for  more  information  about  the  relationship  between  generic  practice  2.9 
and  the  Process  and  Product  Quality  Assurance  process  area. 
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Examples  of  activities  reviewed  include  the  following: 

•  Objectively  evaluating  processes  and  work  products 

•  Tracking  and  communicating  noncompliance  issues 

Examples  of  work  products  reviewed  include  the  following: 

•  Noncompliance  reports 

•  Evaluation  logs  and  reports 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  process  and 
product  quality  assurance  process  with  higher  level 
management  and  resolve  issues. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 


Continuous/Maturity  Levels  3  -  5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process  and 
product  quality  assurance  process. 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  process  and  product  quality  assurance  process 
to  support  the  future  use  and  improvement  of  the 
organization’s  processes  and  process  assets. 
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Continuous/Maturity  Levels  3  -  5  Only 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Evaluation  logs 

•  Quality  trends 

•  Noncompliance  report 

•  Status  reports  of  corrective  action 

•  Cost  of  quality  reports  for  the  project 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  process 
and  product  quality  assurance  process,  which  address  quality 
and  process  performance,  based  on  customer  needs  and 
business  objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  process  and  product  quality 
assurance  process  to  achieve  the  established  quantitative 
quality  and  process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  process  and  product 
quality  assurance  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  process  and  product  quality  assurance 
process. 
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QUANTITATIVE  PROJECT  MANAGEMENT 

A  Project  Management  Process  Area  at  Maturity  Level  4 


Purpose 


The  purpose  of  Quantitative  Project  Management  (QPM)  is  to 
quantitatively  manage  the  project’s  defined  process  to  achieve  the 
project’s  established  quality  and  process-performance  objectives. 


Introductory  Notes 


The  Quantitative  Project  Management  process  area  involves  the 
following: 

•  Establishing  and  maintaining  the  project’s  quality  and  process- 
performance  objectives 

•  Identifying  suitable  subprocesses  that  compose  the  project’s 
defined  process  based  on  historical  stability  and  capability  data 
found  in  process-performance  baselines  or  models 

•  Selecting  the  subprocesses  of  the  project’s  defined  process  to  be 
statistically  managed 

•  Monitoring  the  project  to  determine  whether  the  project’s  objectives 
for  quality  and  process  performance  are  being  satisfied,  and 
identifying  appropriate  corrective  action 

•  Selecting  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses 

•  Establishing  and  maintaining  an  understanding  of  the  variation  of 
the  selected  subprocesses  using  the  selected  measures  and 
analytic  techniques 

•  Monitoring  the  performance  of  the  selected  subprocesses  to 
determine  whether  they  are  capable  of  satisfying  their  quality  and 
process-performance  objectives,  and  identifying  corrective  action 

•  Recording  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository 

The  quality  and  process-performance  objectives,  measures,  and 
baselines  identified  here  are  developed  as  described  in  the 
Organizational  Process  Performance  process  area.  Subsequently,  the 
results  of  performing  the  processes  associated  with  the  Quantitative 
Project  Management  process  area  (e.g.,  measurement  definitions  and 
measurement  data)  become  part  of  the  organizational  process  assets 
referred  to  in  the  Organizational  Process  Performance  process  area. 
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To  effectively  address  the  specific  practices  in  this  process  area,  the 
organization  should  have  already  established  a  set  of  standard 
processes  and  related  organizational  process  assets,  such  as  the 
organization’s  measurement  repository  and  the  organization’s  process 
asset  library  for  use  by  each  project  in  establishing  its  defined  process. 
The  project’s  defined  process  is  a  set  of  subprocesses  that  form  an 
integrated  and  coherent  lifecycle  for  the  project.  It  is  established,  in  part, 
through  selecting  and  tailoring  processes  from  the  organization’s  set  of 
standard  processes.  (See  the  definition  of  “defined  process”  in  the 
glossary.) 

The  project  should  also  ensure  that  the  measurements  and  progress  of 
the  supplier’s  efforts  are  made  available.  Establishment  of  effective 
relationships  with  suppliers  is  necessary  for  the  successful 
implementation  of  this  process  area’s  specific  practices. 

Process  performance  is  a  measure  of  the  actual  process  results 
achieved.  Process  performance  is  characterized  by  both  process 
measures  (e.g.,  effort,  cycle  time,  and  defect  removal  efficiency)  and 
product  measures  (e.g.,  reliability,  defect  density,  and  response  time). 

Subprocesses  are  defined  components  of  a  larger  defined  process.  For 
example,  a  typical  organization’s  development  process  may  be  defined 
in  terms  of  subprocesses  such  as  requirements  development,  design, 
build,  test,  and  peer  review.  The  subprocesses  themselves  may  be 
further  decomposed  as  necessary  into  other  subprocesses  and  process 
elements. 

One  essential  element  of  quantitative  management  is  having 
confidence  in  estimates  (i.e. ,  being  able  to  predict  the  extent  to  which 
the  project  can  fulfill  its  quality  and  process-performance  objectives). 
The  subprocesses  that  will  be  statistically  managed  are  chosen  based 
on  identified  needs  for  predictable  performance.  (See  the  definitions  of 
“statistically  managed  process,”  “quality  and  process-performance 
objective,”  and  “quantitatively  managed  process”  in  the  glossary.) 

Another  essential  element  of  quantitative  management  is  understanding 
the  nature  and  extent  of  the  variation  experienced  in  process 
performance,  and  recognizing  when  the  project’s  actual  performance 
may  not  be  adequate  to  achieve  the  project’s  quality  and  process- 
performance  objectives. 

Statistical  management  involves  statistical  thinking  and  the  correct  use 
of  a  variety  of  statistical  techniques,  such  as  run  charts,  control  charts, 
confidence  intervals,  prediction  intervals,  and  tests  of  hypotheses. 
Quantitative  management  uses  data  from  statistical  management  to 
help  the  project  predict  whether  it  will  be  able  to  achieve  its  quality  and 
process-performance  objectives  and  identify  what  corrective  action 
should  be  taken. 
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This  process  area  applies  to  managing  a  project,  but  the  concepts 
found  here  also  apply  to  managing  other  groups  and  functions.  Applying 
these  concepts  to  managing  other  groups  and  functions  may  not 
necessarily  contribute  to  achieving  the  organization’s  business 
objectives,  but  may  help  these  groups  and  functions  control  their  own 
processes. 


Examples  of  other  groups  and  functions  include  the  following: 

•  Quality  assurance 

•  Process  definition  and  improvement 

•  Effort  reporting 

•  Customer  complaint  handling 

•  Problem  tracking  and  reporting 


Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  and  taking 
corrective  action. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurable  objectives,  specifying  the 
measures  and  analyses  to  be  performed,  obtaining  and  analyzing 
measures,  and  providing  results. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  quality  and  process- 
performance  objectives,  process-performance  analyses,  process- 
performance  baselines,  and  process-performance  models. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  including  the 
organization’s  measurement  repository. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  and  maintaining  the  project’s  defined 
process. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  how  to  identify  the  causes  of  defects  and  other 
problems,  and  taking  action  to  prevent  them  from  occurring  in  the 
future. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  selecting  and  deploying  improvements  that 
support  the  organization’s  quality  and  process-performance  objectives. 
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Specific  Goal  and  Practice  Summary 

SG  1  Quantitatively  Manage  the  Project 

SP  1 .1  Establish  the  Project’s  Objectives 
SP  1 .2  Compose  the  Defined  Process 

SP  1 .3  Select  the  Subprocesses  that  Will  Be  Statistically  Managed 
SP  1 .4  Manage  Project  Performance 
SG  2  Statistically  Manage  Subprocess  Performance 

SP  2.1  Select  Measures  and  Analytic  Techniques 
SP  2.2  Apply  Statistical  Methods  to  Understand  Variation 
SP  2.3  Monitor  Performance  of  the  Selected  Subprocesses 
SP  2.4  Record  Statistical  Management  Data 


Specific  Practices  by  Goal 


SG  1  Quantitatively  Manage  the  Project 

The  project  is  quantitatively  managed  using  quality  and  process- 
performance  objectives. 


SP  1.1  Establish  the  Project’s  Objectives 

Establish  and  maintain  the  project’s  quality  and  process- 
performance  objectives. 


When  establishing  the  project’s  quality  and  process-performance 
objectives,  it  is  often  useful  to  think  ahead  about  which  processes  from 
the  organization’s  set  of  standard  processes  will  be  included  in  the 
project’s  defined  process,  and  what  the  historical  data  indicates 
regarding  their  process  performance.  These  considerations  will  help  in 
establishing  realistic  objectives  for  the  project.  Later,  as  the  project’s 
actual  performance  becomes  known  and  more  predictable,  the 
objectives  may  need  to  be  revised. 

Typical  Work  Products 

1 .  The  project’s  quality  and  process-performance  objectives 
Subpractices 

1 .  Review  the  organization's  objectives  for  quality  and  process 
performance. 

The  intent  of  this  review  is  to  ensure  that  the  project  understands  the  broader 
business  context  in  which  the  project  will  need  to  operate.  The  project’s  objectives 
for  quality  and  process  performance  are  developed  in  the  context  of  these 
overarching  organizational  objectives. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  quality  and  process- 
performance  objectives. 


Quantitative  Project  Management  (QPM) 


367 


CMMI  for  Development 
Version  1.2 

2.  Identify  the  quality  and  process  performance  needs  and  priorities  of 
the  customer,  suppliers,  end  users,  and  other  relevant 
stakeholders. 

Examples  of  quality  and  process-performance  attributes  for  which  needs  and 
:  priorities  might  be  identified  include  the  following: 

;  •  Functionality 
|  •  Reliability 
:  •  Maintainability 
i  •  Usability 
|  •  Duration 
i  •  Predictability 
:  •  Timeliness 

•  Accuracy 

3.  Identify  how  process  performance  is  to  be  measured. 

Consider  whether  the  measures  established  by  the  organization  are  adequate  for 
assessing  progress  in  fulfilling  customer,  end-user,  and  other  stakeholder  needs 
and  priorities.  It  may  be  necessary  to  supplement  these  with  additional  measures. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures. 

4.  Define  and  document  measurable  quality  and  process- 
performance  objectives  for  the  project. 

Defining  and  documenting  objectives  for  the  project  involve  the  following: 

•  Incorporating  the  organization’s  quality  and  process-performance  objectives 

•  Writing  objectives  that  reflect  the  quality  and  process-performance  needs  and 
priorities  of  the  customer,  end  users,  and  other  stakeholders,  and  the  way  these 
objectives  should  be  measured 

Examples  of  quality  attributes  for  which  objectives  might  be  written  include  the 
:  following: 

i  •  Mean  time  between  failures 
|  •  Critical  resource  utilization 
i  •  Number  and  severity  of  defects  in  the  released  product 
:  •  Number  and  severity  of  customer  complaints  concerning  the  provided  service 
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Examples  of  process-performance  attributes  for  which  objectives  might  be  written 
include  the  following: 

•  Percentage  of  defects  removed  by  product  verification  activities  (perhaps  by  type 
of  verification,  such  as  peer  reviews  and  testing) 

•  Defect  escape  rates 

•  Number  and  density  of  defects  (by  severity)  found  during  the  first  year  following 
product  delivery  (or  start  of  service) 

•  Cycle  time 

•  Percentage  of  rework  time 


5.  Derive  interim  objectives  for  each  lifecycle  phase,  as  appropriate, 
to  monitor  progress  toward  achieving  the  project’s  objectives. 


An  example  of  a  method  to  predict  future  results  of  a  process  is  the  use  of 
process-performance  models  to  predict  the  latent  defects  in  the  delivered  product 
using  interim  measures  of  defects  identified  during  product  verification  activities 
(e.g.,  peer  reviews  and  testing). 


6.  Resolve  conflicts  among  the  project’s  quality  and  process- 
performance  objectives  (e.g.,  if  one  objective  cannot  be  achieved 
without  compromising  another  objective). 

Resolving  conflicts  involves  the  following: 

•  Setting  relative  priorities  for  the  objectives 

•  Considering  alternative  objectives  in  light  of  long-term  business  strategies  as  well 
as  short-term  needs 

•  Involving  the  customer,  end  users,  senior  management,  project  management,  and 
other  relevant  stakeholders  in  the  tradeoff  decisions 

•  Revising  the  objectives  as  necessary  to  reflect  the  results  of  the  conflict  resolution 

7.  Establish  traceability  to  the  project’s  quality  and  process- 
performance  objectives  from  their  sources. 


Examples  of  sources  for  objectives  include  the  following: 

:  •  Requirements 

i  •  Organization’s  quality  and  process-performance  objectives 
j  •  Customer’s  quality  and  process-performance  objectives 
:  •  Business  objectives 

i  •  Discussions  with  customers  and  potential  customers 
•  Market  surveys 
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An  example  of  a  method  to  identify  and  trace  these  needs  and  priorities  is  Quality 
Function  Deployment  (QFD). 


8.  Define  and  negotiate  quality  and  process-performance  objectives 
for  suppliers. 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  establishing  and  maintaining  agreements 
with  suppliers. 

9.  Revise  the  project’s  quality  and  process-performance  objectives  as 
necessary. 


SP  1.2  Compose  the  Defined  Process 

Select  the  subprocesses  that  compose  the  project’s  defined 
process  based  on  historical  stability  and  capability  data. 


Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  and  maintaining  the  project’s  defined 
process. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  process  asset  library,  which  might 
include  a  process  element  of  known  and  needed  capability. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  process-performance 
baselines  and  process-performance  models. 

Subprocesses  are  identified  from  the  process  elements  in  the 
organization’s  set  of  standard  processes  and  the  process  artifacts  in  the 
organization’s  process  asset  library. 

Typical  Work  Products 

1.  Criteria  used  in  identifying  which  subprocesses  are  valid 
candidates  for  inclusion  in  the  project’s  defined  process 

2.  Candidate  subprocesses  for  inclusion  in  the  project’s  defined 
process 

3.  Subprocesses  to  be  included  in  the  project’s  defined  process 

4.  Identified  risks  when  selected  subprocesses  lack  a  process- 
performance  history 

Subpractices 

1 .  Establish  the  criteria  to  use  in  identifying  which  subprocesses  are 
valid  candidates  for  use. 
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Identification  may  be  based  on  the  following: 

•  Quality  and  process-performance  objectives 

•  Existence  of  process-performance  data 

•  Product  line  standards 

•  Project  lifecycle  models 

•  Customer  requirements 

•  Laws  and  regulations 

2.  Determine  whether  the  subprocesses  that  are  to  be  statistically 
managed,  and  that  were  obtained  from  the  organizational  process 
assets,  are  suitable  for  statistical  management. 

A  subprocess  may  be  more  suitable  for  statistical  management  if  it  has  a  history 
of  the  following: 

•  Stable  performance  in  previous  comparable  instances 

•  Process-performance  data  that  satisfies  the  project’s  quality  and  process- 
performance  objectives 

Historical  data  are  primarily  obtained  from  the  organization’s  process-performance 
baselines.  However,  these  data  may  not  be  available  for  all  subprocesses. 

3.  Analyze  the  interaction  of  subprocesses  to  understand  the 
relationships  among  the  subprocesses  and  the  measured  attributes 
of  the  subprocesses. 


Examples  of  analysis  techniques  include  system  dynamics  models  and 
simulations. 


4.  Identify  the  risk  when  no  subprocess  is  available  that  is  known  to 
be  capable  of  satisfying  the  quality  and  process-performance 
objectives  (i.e.,  no  capable  subprocess  is  available  or  the  capability 
of  the  subprocess  is  not  known). 

Even  when  a  subprocess  has  not  been  selected  to  be  statistically  managed, 
historical  data  and  process-performance  models  may  indicate  that  the  subprocess 
is  not  capable  of  satisfying  the  quality  and  process-performance  objectives. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  risk  identification  and  analysis. 


SP  1.3  Select  the  Subprocesses  that  Will  Be  Statistically  Managed 

Select  the  subprocesses  of  the  project's  defined  process  that 
will  be  statistically  managed. 


Selecting  the  subprocesses  to  be  statistically  managed  is  often  a 
concurrent  and  iterative  process  of  identifying  applicable  project  and 
organization  quality  and  process-performance  objectives,  selecting  the 
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subprocesses,  and  identifying  the  process  and  product  attributes  to 
measure  and  control.  Often  the  selection  of  a  process,  quality  and 
process-performance  objective,  or  measurable  attribute  will  constrain 
the  selection  of  the  other  two.  For  example,  if  a  particular  process  is 
selected,  the  measurable  attributes  and  quality  and  process- 
performance  objectives  may  be  constrained  by  that  process. 

Typical  Work  Products 

1 .  Quality  and  process-performance  objectives  that  will  be  addressed 
by  statistical  management 

2.  Criteria  used  in  selecting  which  subprocesses  will  be  statistically 
managed 

3.  Subprocesses  that  will  be  statistically  managed 

4.  Identified  process  and  product  attributes  of  the  selected 
subprocesses  that  should  be  measured  and  controlled 

Subpractices 

1 .  Identify  which  of  the  quality  and  process-performance  objectives  of 
the  project  will  be  statistically  managed. 

2.  Identify  the  criteria  to  be  used  in  selecting  the  subprocesses  that 
are  the  main  contributors  to  achieving  the  identified  quality  and 
process-performance  objectives  and  for  which  predictable 
performance  is  important. 


:  Examples  of  sources  for  criteria  used  in  selecting  subprocesses  include  the 
i  following: 

|  •  Customer  requirements  related  to  quality  and  process  performance 
|  •  Quality  and  process-performance  objectives  established  by  the  customer 
:  •  Quality  and  process-performance  objectives  established  by  the  organization 
I  •  Organization’s  performance  baselines  and  models 
|  •  Stable  performance  of  the  subprocess  on  other  projects 
:  •  Laws  and  regulations 


3.  Select  the  subprocesses  that  will  be  statistically  managed  using  the 
selection  criteria. 

It  may  not  be  possible  to  statistically  manage  some  subprocesses  (e.g.,  where 
new  subprocesses  and  technologies  are  being  piloted).  In  other  cases,  it  may  not 
be  economically  justifiable  to  apply  statistical  techniques  to  certain  subprocesses. 

4.  Identify  the  product  and  process  attributes  of  the  selected 
subprocesses  that  will  be  measured  and  controlled. 
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Examples  of  product  and  process  attributes  include  the  following: 

•  Defect  density 

•  Cycle  time 

•  Test  coverage 


SP  1.4  Manage  Project  Performance 

Monitor  the  project  to  determine  whether  the  project’s 
objectives  for  quality  and  process  performance  will  be 
satisfied,  and  identify  corrective  action  as  appropriate. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  and  using  measures. 

A  prerequisite  for  such  a  comparison  is  that  the  selected  subprocesses 
of  the  project’s  defined  process  are  being  statistically  managed  and 
their  process  capability  is  understood.  The  specific  practices  of  specific 
goal  2  provide  detail  on  statistically  managing  the  selected 
subprocesses. 

Typical  Work  Products 

1 .  Estimates  (predictions)  of  the  achievement  of  the  project’s  quality 
and  process-performance  objectives 

2.  Documentation  of  the  risks  in  achieving  the  project’s  quality  and 
process-performance  objectives 

3.  Documentation  of  actions  needed  to  address  the  deficiencies  in 
achieving  the  project’s  objectives 

Subpractices 

1 .  Periodically  review  the  performance  of  each  subprocess  and  the 
capability  of  each  subprocess  selected  to  be  statistically  managed 
to  appraise  progress  toward  achieving  the  project’s  quality  and 
process-performance  objectives. 

The  process  capability  of  each  selected  subprocess  is  determined  with  respect  to 
that  subprocess’  established  quality  and  process-performance  objectives.  These 
objectives  are  derived  from  the  project’s  quality  and  process-performance 
objectives,  which  are  for  the  project  as  a  whole. 

2.  Periodically  review  the  actual  results  achieved  against  established 
interim  objectives  for  each  phase  of  the  project  lifecycle  to  appraise 
progress  toward  achieving  the  project’s  quality  and  process- 
performance  objectives. 

3.  Track  suppliers’  results  for  achieving  their  quality  and  process- 
performance  objectives. 


Quantitative  Project  Management  (QPM) 


373 


CMMI  for  Development 
Version  1.2 

4.  Use  process-performance  models  calibrated  with  obtained 
measures  of  critical  attributes  to  estimate  progress  toward 
achieving  the  project’s  quality  and  process-performance  objectives. 

Process-performance  models  are  used  to  estimate  progress  toward  achieving 
objectives  that  cannot  be  measured  until  a  future  phase  in  the  project  lifecycle.  An 
example  is  the  use  of  process-performance  models  to  predict  the  latent  defects  in 
the  delivered  product  using  interim  measures  of  defects  identified  during  peer 
reviews. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process-performance  models. 

The  calibration  is  based  on  the  results  obtained  from  performing  the  previous 
subpractices. 

5.  Identify  and  manage  the  risks  associated  with  achieving  the 
project’s  quality  and  process-performance  objectives. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  managing  risks. 


Example  sources  of  the  risks  include  the  following: 

•  Inadequate  stability  and  capability  data  in  the  organization’s  measurement 
repository 

•  Subprocesses  having  inadequate  performance  or  capability 

•  Suppliers  not  achieving  their  quality  and  process-performance  objectives 

•  Lack  of  visibility  into  supplier  capability 

•  Inaccuracies  in  the  organization’s  process-performance  models  for  predicting 
future  performance 

•  Deficiencies  in  predicted  process  performance  (estimated  progress) 

•  Other  identified  risks  associated  with  identified  deficiencies 


6.  Determine  and  document  actions  needed  to  address  the 
deficiencies  in  achieving  the  project’s  quality  and  process- 
performance  objectives. 

The  intent  of  these  actions  is  to  plan  and  deploy  the  right  set  of  activities, 
resources,  and  schedule  to  place  the  project  back  on  track  as  much  as  possible  to 
meet  its  objectives. 
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Examples  of  actions  that  can  be  taken  to  address  deficiencies  in  achieving  the 
:  project’s  objectives  include  the  following: 

j  •  Changing  quality  or  process-performance  objectives  so  that  they  are  within  the 
j  expected  range  of  the  project’s  defined  process 

:  •  Improving  the  implementation  of  the  project’s  defined  process  so  as  to  reduce  its 
normal  variability  (reducing  variability  may  bring  the  project’s  performance  within 
:  the  objectives  without  having  to  move  the  mean) 

:  •  Adopting  new  subprocesses  and  technologies  that  have  the  potential  for  satisfying 
i  the  objectives  and  managing  the  associated  risks 

j  •  Identifying  the  risk  and  risk  mitigation  strategies  for  the  deficiencies 

•  Terminating  the  project 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 


SG  2  Statistically  Manage  Subprocess  Performance 

The  performance  of  selected  subprocesses  within  the  project's  defined 
process  is  statistically  managed. 

This  specific  goal  describes  an  activity  critical  to  achieving  the 
Quantitatively  Manage  the  Project  specific  goal  of  this  process  area. 
The  specific  practices  under  this  specific  goal  describe  how  to 
statistically  manage  the  subprocesses  whose  selection  was  described 
in  the  specific  practices  under  the  first  specific  goal.  When  the  selected 
subprocesses  are  statistically  managed,  their  capability  to  achieve  their 
objectives  can  be  determined.  By  these  means,  it  will  be  possible  to 
predict  whether  the  project  will  be  able  to  achieve  its  objectives,  which 
is  key  to  quantitatively  managing  the  project. 


SP  2.1  Select  Measures  and  Analytic  Techniques 

Select  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurable  objectives;  on  defining, 
collecting,  and  analyzing  measures;  and  on  revising  measures  and 
statistical  analysis  techniques. 

Typical  Work  Products 

1 .  Definitions  of  the  measures  and  analytic  techniques  to  be  used  in 
(or  proposed  for)  statistically  managing  the  subprocesses 

2.  Operational  definitions  of  the  measures,  their  collection  points  in 
the  subprocesses,  and  how  the  integrity  of  the  measures  will  be 
determined 
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3.  Traceability  of  measures  back  to  the  project’s  quality  and  process- 
performance  objectives 

4.  Instrumented  organizational  support  environment  to  support 
automatic  data  collection 

Subpractices 

1 .  Identify  common  measures  from  the  organizational  process  assets 
that  support  statistical  management. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  common  measures. 

Product  lines  or  other  stratification  criteria  may  categorize  common  measures. 

2.  Identify  additional  measures  that  may  be  needed  for  this  instance 
to  cover  critical  product  and  process  attributes  of  the  selected 
subprocesses. 

In  some  cases,  measures  may  be  research  oriented.  Such  measures  should  be 
explicitly  identified. 

3.  Identify  the  measures  that  are  appropriate  for  statistical 
management. 

Critical  criteria  for  selecting  statistical  management  measures  include  the 
following: 

•  Controllable  (e.g.,  can  a  measure’s  values  be  changed  by  changing  how  the 
subprocess  is  implemented?) 

•  Adequate  performance  indicator  (e.g.,  is  the  measure  a  good  indicator  of  how  well 
the  subprocess  is  performing  relative  to  the  objectives  of  interest?) 


Examples  of  subprocess  measures  include  the  following: 

•  Requirements  volatility 

•  Ratios  of  estimated  to  measured  values  of  the  planning  parameters  (e.g.,  size, 
cost,  and  schedule) 

•  Coverage  and  efficiency  of  peer  reviews 

•  Test  coverage  and  efficiency 

•  Effectiveness  of  training  (e.g.,  percent  of  planned  training  completed  and  test 
scores) 

•  Reliability 

•  Percentage  of  the  total  defects  inserted  or  found  in  the  different  phases  of  the 
project  lifecycle 

•  Percentage  of  the  total  effort  expended  in  the  different  phases  of  the  project 
lifecycle 
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4.  Specify  the  operational  definitions  of  the  measures,  their  collection 
points  in  the  subprocesses,  and  how  the  integrity  of  the  measures 
will  be  determined. 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They 
address  two  important  criteria  as  follows: 

•  Communication:  What  has  been  measured,  how  it  was  measured,  what  the  units 
of  measure  are,  and  what  has  been  included  or  excluded 

•  Repeatability:  Whether  the  measurement  can  be  repeated,  given  the  same 
definition,  to  get  the  same  results 

5.  Analyze  the  relationship  of  the  identified  measures  to  the 
organization’s  and  project’s  objectives,  and  derive  objectives  that 
state  specific  target  measures  or  ranges  to  be  met  for  each 
measured  attribute  of  each  selected  subprocess. 

6.  Instrument  the  organizational  support  environment  to  support 
collection,  derivation,  and  analysis  of  statistical  measures. 

The  instrumentation  is  based  on  the  following: 

•  Description  of  the  organization’s  set  of  standard  processes 

•  Description  of  the  project’s  defined  process 

•  Capabilities  of  the  organizational  support  environment 

7.  Identify  the  appropriate  statistical  analysis  techniques  that  are 
expected  to  be  useful  in  statistically  managing  the  selected 
subprocesses. 

The  concept  of  “one  size  does  not  fit  all”  applies  to  statistical  analysis  techniques. 
What  makes  a  particular  technique  appropriate  is  not  just  the  type  of  measures, 
but  more  important,  how  the  measures  will  be  used  and  whether  the  situation 
warrants  applying  that  technique.  The  appropriateness  of  the  selection  may  need 
to  be  investigated  from  time  to  time. 

Examples  of  statistical  analysis  techniques  are  given  in  the  next  specific  practice. 

8.  Revise  the  measures  and  statistical  analysis  techniques  as 
necessary. 


SP  2.2  Apply  Statistical  Methods  to  Understand  Variation 

Establish  and  maintain  an  understanding  of  the  variation  of  the 
selected  subprocesses  using  the  selected  measures  and 
analytic  techniques. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  collecting,  analyzing,  and  using  measurement  results. 
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Understanding  variation  is  achieved,  in  part,  by  collecting  and  analyzing 
process  and  product  measures  so  that  special  causes  of  variation  can 
be  identified  and  addressed  to  achieve  predictable  performance. 

A  special  cause  of  process  variation  is  characterized  by  an  unexpected 
change  in  process  performance.  Special  causes  are  also  known  as 
“assignable  causes”  because  they  can  be  identified,  analyzed,  and 
addressed  to  prevent  recurrence. 

The  identification  of  special  causes  of  variation  is  based  on  departures 
from  the  system  of  common  causes  of  variation.  These  departures  can 
be  identified  by  the  presence  of  extreme  values,  or  other  identifiable 
patterns  in  the  data  collected  from  the  subprocess  or  associated  work 
products.  Knowledge  of  variation  and  insight  about  potential  sources  of 
anomalous  patterns  are  typically  needed  to  detect  special  causes  of 
variation. 


Sources  of  anomalous  patterns  of  variation  may  include  the  following: 

•  Lack  of  process  compliance 

•  Undistinguished  influences  of  multiple  underlying  subprocesses  on  the  data 

•  Ordering  or  timing  of  activities  within  the  subprocess 

•  Uncontrolled  inputs  to  the  subprocess 

•  Environmental  changes  during  subprocess  execution 

•  Schedule  pressure 

•  Inappropriate  sampling  or  grouping  of  data 


Typical  Work  Products 

1.  Collected  measures 

2.  Natural  bounds  of  process  performance  for  each  measured 
attribute  of  each  selected  subprocess 

3.  Process  performance  compared  to  the  natural  bounds  of  process 
performance  for  each  measured  attribute  of  each  selected 
subprocess 

Subpractices 

1 .  Establish  trial  natural  bounds  for  subprocesses  having  suitable 
historical  performance  data. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  organizational  process-performance 
baselines. 

Natural  bounds  of  an  attribute  are  the  range  within  which  variation  normally 
occurs.  All  processes  will  show  some  variation  in  process  and  product  measures 
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each  time  they  are  executed.  The  issue  is  whether  this  variation  is  due  to  common 
causes  of  variation  in  the  normal  performance  of  the  process  or  to  some  special 
cause  that  can  and  should  be  identified  and  removed. 

When  a  subprocess  is  initially  executed,  suitable  data  for  establishing  trial  natural 
bounds  are  sometimes  available  from  prior  instances  of  the  subprocess  or 
comparable  subprocesses,  process-performance  baselines,  or  process- 
performance  models.  These  data  are  typically  contained  in  the  organization’s 
measurement  repository.  As  the  subprocess  is  executed,  data  specific  to  that 
instance  are  collected  and  used  to  update  and  replace  the  trial  natural  bounds. 
However,  if  the  subprocess  in  question  has  been  materially  tailored,  or  if  the 
conditions  are  materially  different  from  those  in  previous  instantiations,  the  data  in 
the  repository  may  not  be  relevant  and  should  not  be  used. 

In  some  cases,  there  may  be  no  historical  comparable  data  (e.g.,  when 
introducing  a  new  subprocess,  when  entering  a  new  application  domain,  or  when 
significant  changes  have  been  made  to  the  subprocess).  In  such  cases,  trial 
natural  bounds  will  have  to  be  made  from  early  process  data  of  this  subprocess. 
These  trial  natural  bounds  must  then  be  refined  and  updated  as  subprocess 
execution  continues. 


Examples  of  criteria  for  determining  whether  data  are  comparable  include  the 
following: 

•  Product  lines 

•  Application  domain 

•  Work  product  and  task  attributes  (e.g.,  size  of  product) 

•  Size  of  project 


2.  Collect  data,  as  defined  by  the  selected  measures,  on  the 
subprocesses  as  they  execute. 

3.  Calculate  the  natural  bounds  of  process  performance  for  each 
measured  attribute. 


Examples  of  where  the  natural  bounds  are  calculated  include  the  following: 

•  Control  charts 

•  Confidence  intervals  (for  parameters  of  distributions) 

•  Prediction  intervals  (for  future  outcomes) 


4.  Identify  special  causes  of  variation. 


An  example  of  a  criterion  for  detecting  a  special  cause  of  process  variation  in  a 
control  chart  is  a  data  point  that  falls  outside  of  the  3-sigma  control  limits. 


The  criteria  for  detecting  special  causes  of  variation  are  based  on  statistical  theory 
and  experience  and  depend  on  economic  justification.  As  criteria  are  added, 
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special  causes  are  more  likely  to  be  identified  if  present,  but  the  likelihood  of  false 
alarms  also  increases. 

5.  Analyze  the  special  cause  of  process  variation  to  determine  the 
reasons  the  anomaly  occurred. 


Examples  of  techniques  for  analyzing  the  reasons  for  special  causes  of  variation 
include  the  following: 

•  Cause-and-effect  (fishbone)  diagrams 

•  Designed  experiments 

•  Control  charts  (applied  to  subprocess  inputs  or  to  lower  level  subprocesses) 

•  Subgrouping  (analyzing  the  same  data  segregated  into  smaller  groups  based  on 
an  understanding  of  how  the  subprocess  was  implemented  facilitates  isolation  of 
special  causes) 


Some  anomalies  may  simply  be  extremes  of  the  underlying  distribution  rather 
than  problems.  The  people  implementing  a  subprocess  are  usually  the  ones  best 
able  to  analyze  and  understand  special  causes  of  variation. 

6.  Determine  what  corrective  action  should  be  taken  when  special 
causes  of  variation  are  identified. 

Removing  a  special  cause  of  process  variation  does  not  change  the  underlying 
subprocess.  It  addresses  an  error  in  the  way  the  subprocess  is  being  executed. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

7.  Recalculate  the  natural  bounds  for  each  measured  attribute  of  the 
selected  subprocesses  as  necessary. 

Recalculating  the  (statistically  estimated)  natural  bounds  is  based  on  measured 
values  that  signify  that  the  subprocess  has  changed,  not  on  expectations  or 
arbitrary  decisions. 


Examples  of  when  the  natural  bounds  may  need  to  be  recalculated  include  the 
following: 

•  There  are  incremental  improvements  to  the  subprocess 

•  New  tools  are  deployed  for  the  subprocess 

•  A  new  subprocess  is  deployed 

•  The  collected  measures  suggest  that  the  subprocess  mean  has  permanently 
shifted  or  the  subprocess  variation  has  permanently  changed 
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SP  2.3  Monitor  Performance  of  the  Selected  Subprocesses 

Monitor  the  performance  of  the  selected  subprocesses  to 
determine  their  capability  to  satisfy  their  quality  and  process- 
performance  objectives,  and  identify  corrective  action  as 
necessary. 


The  intent  of  this  specific  practice  is  to  do  the  following: 

•  Determine  statistically  the  process  behavior  expected  from  the 
subprocess 

•  Appraise  the  probability  that  the  process  will  meet  its  quality  and 
process-performance  objectives 

•  Identify  the  corrective  action  to  be  taken,  based  on  a  statistical 
analysis  of  the  process-performance  data 

Corrective  action  may  include  renegotiating  the  affected  project 
objectives,  identifying  and  implementing  alternative  subprocesses,  or 
identifying  and  measuring  lower  level  subprocesses  to  achieve  greater 
detail  in  the  performance  data.  Any  or  all  of  these  actions  are  intended 
to  help  the  project  use  a  more  capable  process.  (See  the  definition  of 
“capable  process”  in  the  glossary.) 

A  prerequisite  for  comparing  the  capability  of  a  selected  subprocess 
against  its  quality  and  process-performance  objectives  is  that  the 
performance  of  the  subprocess  is  stable  and  predictable  with  respect  to 
its  measured  attributes. 

Process  capability  is  analyzed  for  those  subprocesses  and  those 
measured  attributes  for  which  (derived)  objectives  have  been 
established.  Not  all  subprocesses  or  measured  attributes  that  are 
statistically  managed  are  analyzed  regarding  process  capability. 

The  historical  data  may  be  inadequate  for  initially  determining  whether 
the  subprocess  is  capable.  It  also  is  possible  that  the  estimated  natural 
bounds  for  subprocess  performance  may  shift  away  from  the  quality 
and  process-performance  objectives.  In  either  case,  statistical  control 
implies  monitoring  capability  as  well  as  stability. 

Typical  Work  Products 

1 .  Natural  bounds  of  process  performance  for  each  selected 
subprocess  compared  to  its  established  (derived)  objectives 

2.  For  each  subprocess,  its  process  capability 

3.  For  each  subprocess,  the  actions  needed  to  address  deficiencies 
in  its  process  capability 
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Subpractices 

1 .  Compare  the  quality  and  process-performance  objectives  to  the 
natural  bounds  of  the  measured  attribute. 

This  comparison  provides  an  appraisal  of  the  process  capability  for  each 
measured  attribute  of  a  subprocess.  These  comparisons  can  be  displayed 
graphically,  in  ways  that  relate  the  estimated  natural  bounds  to  the  objectives  or 
as  process  capability  indices,  which  summarize  the  relationship  of  the  objectives 
to  the  natural  bounds. 

2.  Monitor  changes  in  quality  and  process-performance  objectives 
and  selected  subprocess’  process  capability. 

3.  Identify  and  document  subprocess  capability  deficiencies. 

4.  Determine  and  document  actions  needed  to  address  subprocess 
capability  deficiencies. 


Examples  of  actions  that  can  be  taken  when  a  selected  subprocess’s 

performance  does  not  satisfy  its  objectives  include  the  following: 

•  Changing  quality  and  process-performance  objectives  so  that  they  are  within  the 
subprocess’  process  capability 

•  Improving  the  implementation  of  the  existing  subprocess  so  as  to  reduce  its 
normal  variability  (reducing  variability  may  bring  the  natural  bounds  within  the 
objectives  without  having  to  move  the  mean) 

•  Adopting  new  process  elements  and  subprocesses  and  technologies  that  have 
the  potential  for  satisfying  the  objectives  and  managing  the  associated  risks 

•  Identifying  risks  and  risk  mitigation  strategies  for  each  subprocess’s  process 
capability  deficiency 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 


SP  2.4  Record  Statistical  Management  Data 

Record  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  managing  and  storing  data,  measurement  definitions, 
and  results. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  measurement  repository. 

Typical  Work  Products 

1 .  Statistical  and  quality  management  data  recorded  in  the 
organization’s  measurement  repository 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1 

Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  quantitative  project 
management  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  quantitative  project  management  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  quantitatively 
managing  the  project  using  quality  and  process-performance  objectives, 
and  statistically  managing  selected  subprocesses  within  the  project’s 
defined  process. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  quantitative 
project  management  process. 
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Elaboration: 

This  plan  for  performing  the  quantitative  project  management  process 
can  be  included  in  (or  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  quantitative 
project  management  process,  developing  the  work  products, 
and  providing  the  services  of  the  process. 


Elaboration: 

Special  expertise  in  statistics  and  statistical  process  control  may  be 
needed  to  define  the  techniques  for  statistical  management  of  selected 
subprocesses,  but  staff  will  use  the  tools  and  techniques  to  perform  the 
statistical  management.  Special  expertise  in  statistics  may  also  be 
needed  for  analyzing  and  interpreting  the  measures  resulting  from 
statistical  management. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  System  dynamics  models 

•  Automated  test-coverage  analyzers 

•  Statistical  process  and  quality  control  packages 

•  Statistical  analysis  packages 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  quantitative  project  management  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  quantitative 
project  management  process  as  needed. 

Elaboration: 

:  Examples  of  training  topics  include  the  following: 

;  •  Process  modeling  and  analysis 
•  Process  measurement  data  selection,  definition,  and  collection 
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GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  quantitative  project 
management  process  under  appropriate  levels  of  control. 

Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Subprocesses  to  be  included  in  the  project’s  defined  process 

:  •  Operational  definitions  of  the  measures,  their  collection  points  in  the  subprocesses, 

■  and  how  the  integrity  of  the  measures  will  be  determined 

:  •  Collected  measures 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
quantitative  project  management  process  as  planned. 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Establishing  project  objectives 

i  •  Resolving  issues  among  the  project’s  quality  and  process-performance  objectives 

i  •  Appraising  performance  of  the  selected  subprocesses 

j  •  Identifying  and  managing  the  risks  in  achieving  the  project’s  quality  and  process- 
:  performance  objectives 

;  •  Identifying  what  corrective  action  should  be  taken 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  quantitative  project  management 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 

the  following: 

•  Profile  of  subprocesses  under  statistical  management  (e.g.,  number  planned  to  be 
under  statistical  management,  number  currently  being  statistically  managed,  and 
number  that  are  statistically  stable) 

•  Number  of  special  causes  of  variation  identified 

•  Schedule  of  data  collection,  analysis,  and  reporting  activities  in  a  measurement 
and  analysis  cycle  as  it  relates  to  quantitative  management  activities 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  quantitative  project 
management  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

|  •  Quantitatively  managing  the  project  using  quality  and  process-performance 
:  objectives 

•  Statistically  managing  selected  subprocesses  within  the  project’s  defined  process 

Examples  of  work  products  reviewed  include  the  following: 

j  •  Subprocesses  to  be  included  in  the  project’s  defined  process 
j  •  Operational  definitions  of  the  measures 

:  •  Collected  measures 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  quantitative 
project  management  process  with  higher  level  management 
and  resolve  issues. 

Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  quantitative 
project  management  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  quantitative  project  management  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 
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Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Records  of  statistical  and  quality  management  data  from  the  project,  including 
results  from  the  periodic  review  of  the  actual  performance  of  the  statistically 
managed  subprocesses  against  established  interim  objectives  of  the  project 

•  Process  and  product  quality  assurance  report  that  identifies  inconsistent  but 
compliant  implementations  of  subprocesses  being  considered  for  statistical 
management 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
quantitative  project  management  process,  which  address 
quality  and  process  performance,  based  on  customer  needs 
and  business  objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  quantitative  project  management 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  quantitative  project 
management  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  quantitative  project  management  process. 
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REQUIREMENTS  DEVELOPMENT 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Requirements  Development  (RD)  is  to  produce  and 
analyze  customer,  product,  and  product  component  requirements. 


Introductory  Notes 


This  process  area  describes  three  types  of  requirements:  customer 
requirements,  product  requirements,  and  product  component 
requirements.  Taken  together,  these  requirements  address  the  needs  of 
relevant  stakeholders,  including  those  pertinent  to  various  product 
lifecycle  phases  (e.g.,  acceptance  testing  criteria)  and  product  attributes 
(e.g.,  safety,  reliability,  and  maintainability).  Requirements  also  address 
constraints  caused  by  the  selection  of  design  solutions  (e.g.,  integration 
of  commercial  off-the-shelf  products). 

All  development  projects  have  requirements.  In  the  case  of  a  project 
that  is  focused  on  maintenance  activities,  the  changes  to  the  product  or 
product  components  are  based  on  changes  to  the  existing 
requirements,  design,  or  implementation.  The  requirements  changes,  if 
any,  might  be  documented  in  change  requests  from  the  customer  or 
users,  or  they  might  take  the  form  of  new  requirements  received  from 
the  requirements  development  process.  Regardless  of  their  source  or 
form,  the  maintenance  activities  that  are  driven  by  changes  to 
requirements  are  managed  accordingly. 

Requirements  are  the  basis  for  design.  The  development  of 
requirements  includes  the  following  activities: 

•  Elicitation,  analysis,  validation,  and  communication  of  customer 
needs,  expectations,  and  constraints  to  obtain  customer 
requirements  that  constitute  an  understanding  of  what  will  satisfy 
stakeholders 

•  Collection  and  coordination  of  stakeholder  needs 

•  Development  of  the  lifecycle  requirements  of  the  product 

•  Establishment  of  the  customer  requirements 

•  Establishment  of  initial  product  and  product  component 
requirements  consistent  with  customer  requirements 
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This  process  area  addresses  all  customer  requirements  rather  than  only 
product-level  requirements  because  the  customer  may  also  provide 
specific  design  requirements. 

Customer  requirements  are  further  refined  into  product  and  product 
component  requirements.  In  addition  to  customer  requirements,  product 
and  product  component  requirements  are  derived  from  the  selected 
design  solutions.  Throughout  the  process  areas,  where  we  use  the 
terms  product  and  product  component,  their  intended  meanings  also 
encompass  services  and  their  components. 

Requirements  are  identified  and  refined  throughout  the  phases  of  the 
product  lifecycle.  Design  decisions,  subsequent  corrective  actions,  and 
feedback  during  each  phase  of  the  product’s  lifecycle  are  analyzed  for 
impact  on  derived  and  allocated  requirements. 

The  Requirements  Development  process  area  includes  three  specific 
goals.  The  Develop  Customer  Requirements  specific  goal  addresses 
defining  a  set  of  customer  requirements  to  use  in  the  development  of 
product  requirements.  The  Develop  Product  Requirements  specific  goal 
addresses  defining  a  set  of  product  or  product  component  requirements 
to  use  in  the  design  of  products  and  product  components.  The  Analyze 
and  Validate  Requirements  specific  goal  addresses  the  necessary 
analysis  of  customer,  product,  and  product  component  requirements  to 
define,  derive,  and  understand  the  requirements.  The  specific  practices 
of  the  third  specific  goal  are  intended  to  assist  the  specific  practices  in 
the  first  two  specific  goals.  The  processes  associated  with  the 
Requirements  Development  process  area  and  those  associated  with 
the  Technical  Solution  process  area  may  interact  recursively  with  one 
another. 

Analyses  are  used  to  understand,  define,  and  select  the  requirements 
at  all  levels  from  competing  alternatives.  These  analyses  include  the 
following: 

•  Analysis  of  needs  and  requirements  for  each  product  lifecycle 
phase,  including  needs  of  relevant  stakeholders,  the  operational 
environment,  and  factors  that  reflect  overall  customer  and  end-user 
expectations  and  satisfaction,  such  as  safety,  security,  and 
affordability 

•  Development  of  an  operational  concept 

•  Definition  of  the  required  functionality 

The  definition  of  functionality,  also  referred  to  as  “functional  analysis,”  is 
not  the  same  as  structured  analysis  in  software  development  and  does 
not  presume  a  functionally  oriented  software  design.  In  object-oriented 
software  design,  it  relates  to  defining  what  are  called  “services”  or 
“methods.”  The  definition  of  functions,  their  logical  groupings,  and  their 
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association  with  requirements  is  referred  to  as  a  “functional 
architecture.” 

Analyses  occur  recursively  at  successively  more  detailed  layers  of  a 
product’s  architecture  until  sufficient  detail  is  available  to  enable 
detailed  design,  acquisition,  and  testing  of  the  product  to  proceed.  As  a 
result  of  the  analysis  of  requirements  and  the  operational  concept 
(including  functionality,  support,  maintenance,  and  disposal),  the 
manufacturing  or  production  concept  produces  more  derived 
requirements,  including  consideration  of  the  following: 

•  Constraints  of  various  types 

•  Technological  limitations 

•  Cost  and  cost  drivers 

•  Time  constraints  and  schedule  drivers 

•  Risks 

•  Consideration  of  issues  implied  but  not  explicitly  stated  by  the 
customer  or  end  user 

•  Factors  introduced  by  the  developer’s  unique  business 
considerations,  regulations,  and  laws 

A  hierarchy  of  logical  entities  (functions  and  subfunctions,  object 
classes  and  subclasses)  is  established  through  iteration  with  the 
evolving  operational  concept.  Requirements  are  refined,  derived,  and 
allocated  to  these  logical  entities.  Requirements  and  logical  entities  are 
allocated  to  products,  product  components,  people,  or  associated 
processes. 

Involvement  of  relevant  stakeholders  in  both  requirements  development 
and  analysis  gives  them  visibility  into  the  evolution  of  requirements. 

This  activity  continually  assures  them  that  the  requirements  are  being 
properly  defined. 


Related  Process  Areas 


Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  customer  and  product  requirements, 
obtaining  agreement  with  the  requirements  provider,  obtaining 
commitments  with  those  implementing  the  requirements,  and 
maintaining  traceability. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
how  the  outputs  of  the  requirements  development  processes  are  used, 
and  the  development  of  alternative  solutions  and  designs  used  in 
refining  and  deriving  requirements. 


390 


Requirements  Development  (RD) 


CMMI  for  Development 
Version  1.2 

Refer  to  the  Product  Integration  process  area  for  more  information 
about  interface  requirements  and  interface  management. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  that  the  resulting  product  meets  the  requirements. 

Refer  to  the  Validation  process  area  for  more  information  about  how  the 
product  built  will  be  validated  against  the  customer  needs. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  managing  risks  that  are  related  to  requirements. 

Refer  to  the  Configuration  Management  process  area  for  information 
about  ensuring  that  key  work  products  are  controlled  and  managed. 

Specific  Goal  and  Practice  Summary 

SG  1  Develop  Customer  Requirements 
SP1.1  Elicit  Needs 

SP  1 .2  Develop  the  Customer  Requirements 

SG  2  Develop  Product  Requirements 

SP  2.1  Establish  Product  and  Product  Component  Requirements 
SP  2.2  Allocate  Product  Component  Requirements 

SP  2.3  Identify  Interface  Requirements 

SG  3  Analyze  and  Validate  Requirements 

SP  3.1  Establish  Operational  Concepts  and  Scenarios 
SP  3.2  Establish  a  Definition  of  Required  Functionality 

SP  3.3  Analyze  Requirements 

SP  3.4  Analyze  Requirements  to  Achieve  Balance 

SP  3.5  Validate  Requirements 


Specific  Practices  by  Goal 


SG  1  Develop  Customer  Requirements 

Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected 
and  translated  into  customer  requirements. 

The  needs  of  stakeholders  (e.g.,  customers,  end  users,  suppliers, 
builders,  testers,  manufacturers,  and  logistics  support  personnel)  are 
the  basis  for  determining  customer  requirements.  The  stakeholder 
needs,  expectations,  constraints,  interfaces,  operational  concepts,  and 
product  concepts  are  analyzed,  harmonized,  refined,  and  elaborated  for 
translation  into  a  set  of  customer  requirements. 

Frequently,  stakeholder  needs,  expectations,  constraints,  and  interfaces 
are  poorly  identified  or  conflicting.  Since  stakeholder  needs, 
expectations,  constraints,  and  limitations  should  be  clearly  identified 
and  understood,  an  iterative  process  is  used  throughout  the  life  of  the 
project  to  accomplish  this  objective.  To  facilitate  the  required 
interaction,  a  surrogate  for  the  end  user  or  customer  is  frequently 
involved  to  represent  their  needs  and  help  resolve  conflicts.  The 
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customer  relations  or  marketing  part  of  the  organization  as  well  as 
members  of  the  development  team  from  disciplines  such  as  human 
engineering  or  support  can  be  used  as  surrogates.  Environmental, 
legal,  and  other  constraints  should  be  considered  when  creating  and 
resolving  the  set  of  customer  requirements. 


SP  1.1  Elicit  Needs 

Elicit  stakeholder  needs,  expectations,  constraints,  and 
interfaces  for  all  phases  of  the  product  lifecycle. 


Eliciting  goes  beyond  collecting  requirements  by  proactively  identifying 
additional  requirements  not  explicitly  provided  by  customers.  Additional 
requirements  should  address  the  various  product  lifecycle  activities  and 
their  impact  on  the  product. 


Examples  of  techniques  to  elicit  needs  include  the  following: 

•  Technology  demonstrations 

•  Interface  control  working  groups 

•  Technical  control  working  groups 

•  Interim  project  reviews 

•  Questionnaires,  interviews,  and  operational  scenarios  obtained  from  end  users 

•  Operational  walkthroughs  and  end-user  task  analysis 

•  Prototypes  and  models 

•  Brainstorming 

•  Quality  Function  Deployment 

•  Market  surveys 

•  Beta  testing 

•  Extraction  from  sources  such  as  documents,  standards,  or  specifications 

•  Observation  of  existing  products,  environments,  and  workflow  patterns 

•  Use  cases 

•  Business  case  analysis 

•  Reverse  engineering  (for  legacy  products) 

•  Customer  satisfaction  surveys 
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Examples  of  sources  of  requirements  that  might  not  be  identified  by  the  customer 
:  include  the  following: 

|  •  Business  policies 

|  •  Standards 

j  •  Business  environmental  requirements  (e.g.,  laboratories,  testing  and  other 
:  facilities,  and  information  technology  infrastructure) 

i  •  Technology 

•  Legacy  products  or  product  components  (reuse  product  components) 


Subpractices 

1 .  Engage  relevant  stakeholders  using  methods  for  eliciting  needs, 
expectations,  constraints,  and  external  interfaces. 


SP  1.2  Develop  the  Customer  Requirements 

Transform  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  customer  requirements. 


The  various  inputs  from  the  relevant  stakeholders  must  be 
consolidated,  missing  information  must  be  obtained,  and  conflicts  must 
be  resolved  in  documenting  the  recognized  set  of  customer 
requirements.  The  customer  requirements  may  include  needs, 
expectations,  and  constraints  with  regard  to  verification  and  validation. 

In  some  situations,  the  customer  provides  a  set  of  requirements  to  the 
project,  or  the  requirements  exist  as  an  output  of  a  previous  project's 
activities.  In  these  situations,  the  customer  requirements  could  conflict 
with  the  relevant  stakeholders'  needs,  expectations,  constraints,  and 
interfaces  and  will  need  to  be  transformed  into  the  recognized  set  of 
customer  requirements  after  appropriate  resolution  of  conflicts. 

Relevant  stakeholders  representing  all  phases  of  the  product's  lifecycle 
should  include  business  as  well  as  technical  functions.  In  this  way, 
concepts  for  all  product-related  lifecycle  processes  are  considered 
concurrently  with  the  concepts  for  the  products.  Customer  requirements 
result  from  informed  decisions  on  the  business  as  well  as  technical 
effects  of  their  requirements. 

Typical  Work  Products 

1.  Customer  requirements 

2.  Customer  constraints  on  the  conduct  of  verification 

3.  Customer  constraints  on  the  conduct  of  validation 
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Subpractices 

1.  Translate  the  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  documented  customer  requirements. 

2.  Define  constraints  for  verification  and  validation. 


SG  2  Develop  Product  Requirements 

Customer  requirements  are  refined  and  elaborated  to  develop  product  and 
product  component  requirements. 

Customer  requirements  are  analyzed  in  conjunction  with  the 
development  of  the  operational  concept  to  derive  more  detailed  and 
precise  sets  of  requirements  called  “product  and  product  component 
requirements.”  Product  and  product  component  requirements  address 
the  needs  associated  with  each  product  lifecycle  phase.  Derived 
requirements  arise  from  constraints,  consideration  of  issues  implied  but 
not  explicitly  stated  in  the  customer  requirements  baseline,  and  factors 
introduced  by  the  selected  architecture,  the  design,  and  the  developer’s 
unique  business  considerations.  The  requirements  are  reexamined  with 
each  successive,  lower  level  set  of  requirements  and  functional 
architecture,  and  the  preferred  product  concept  is  refined. 

The  requirements  are  allocated  to  product  functions  and  product 
components  including  objects,  people,  and  processes.  The  traceability 
of  requirements  to  functions,  objects,  tests,  issues,  or  other  entities  is 
documented.  The  allocated  requirements  and  functions  are  the  basis  for 
the  synthesis  of  the  technical  solution.  As  internal  components  are 
developed,  additional  interfaces  are  defined  and  interface  requirements 
are  established. 

Refer  to  the  Maintain  Bidirectional  Traceability  of  Requirements  specific 
practice  of  the  Requirements  Management  process  area  for  more 
information  about  maintaining  bidirectional  traceability. 


SP  2.1  Establish  Product  and  Product  Component  Requirements 

Establish  and  maintain  product  and  product  component 
requirements,  which  are  based  on  the  customer  requirements. 


The  customer  requirements  may  be  expressed  in  the  customer’s  terms 
and  may  be  nontechnical  descriptions.  The  product  requirements  are 
the  expression  of  these  requirements  in  technical  terms  that  can  be 
used  for  design  decisions.  An  example  of  this  translation  is  found  in  the 
first  House  of  Quality  Function  Deployment,  which  maps  customer 
desires  into  technical  parameters.  For  instance,  “solid  sounding  door” 
might  be  mapped  to  size,  weight,  fit,  dampening,  and  resonant 
frequencies. 
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Product  and  product  component  requirements  address  the  satisfaction 
of  customer,  business,  and  project  objectives  and  associated  attributes, 
such  as  effectiveness  and  affordability. 

Derived  requirements  also  address  the  cost  and  performance  of  other 
lifecycle  phases  (e.g.,  production,  operations,  and  disposal)  to  the 
extent  compatible  with  business  objectives. 

The  modification  of  requirements  due  to  approved  requirement  changes 
is  covered  by  the  “maintain”  function  of  this  specific  practice;  whereas, 
the  administration  of  requirement  changes  is  covered  by  the 
Requirements  Management  process  area. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  changes  to  requirements. 

Typical  Work  Products 

1.  Derived  requirements 

2.  Product  requirements 

3.  Product  component  requirements 

Subpractices 

1 .  Develop  requirements  in  technical  terms  necessary  for  product  and 
product  component  design. 

Develop  architecture  requirements  addressing  critical  product  qualities  and 
performance  necessary  for  product  architecture  design. 

2.  Derive  requirements  that  result  from  design  decisions. 

Refer  to  the  Technical  Solution  process  area  for  more  information 
about  developing  the  solutions  that  generate  additional  derived 
requirements. 

Selection  of  a  technology  brings  with  it  additional  requirements.  For  instance,  use 
of  electronics  requires  additional  technology-specific  requirements  such  as 
electromagnetic  interference  limits. 

3.  Establish  and  maintain  relationships  between  requirements  for 
consideration  during  change  management  and  requirements 
allocation. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability. 

Relationships  between  requirements  can  aid  in  evaluating  the  impact  of  changes. 
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Allocate  Product  Component  Requirements 

Allocate  the  requirements  for  each  product  component. 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
allocation  of  requirements  to  products  and  product  components.  This 
specific  practice  provides  information  for  defining  the  allocation  of 
requirements  but  must  interact  with  the  specific  practices  in  the 
Technical  Solution  process  area  to  establish  solutions  to  which  the 
requirements  are  allocated. 

The  requirements  for  product  components  of  the  defined  solution 
include  allocation  of  product  performance;  design  constraints;  and  fit, 
form,  and  function  to  meet  requirements  and  facilitate  production.  In 
cases  where  a  higher  level  requirement  specifies  performance  that  will 
be  the  responsibility  of  two  or  more  product  components,  the 
performance  must  be  partitioned  for  unique  allocation  to  each  product 
component  as  a  derived  requirement. 

Typical  Work  Products 

1.  Requirement  allocation  sheets 

2.  Provisional  requirement  allocations 

3.  Design  constraints 

4.  Derived  requirements 

5.  Relationships  among  derived  requirements 

Subpractices 

1 .  Allocate  requirements  to  functions. 

2.  Allocate  requirements  to  product  components. 

3.  Allocate  design  constraints  to  product  components. 

4.  Document  relationships  among  allocated  requirements. 

Relationships  include  dependencies  in  which  a  change  in  one  requirement  may 
affect  other  requirements. 

SP  2.3  Identify  Interface  Requirements 

Identify  interface  requirements. 


Interfaces  between  functions  (or  between  objects)  are  identified. 
Functional  interfaces  may  drive  the  development  of  alternative  solutions 
described  in  the  Technical  Solution  process  area. 
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Interface  requirements  between  products  or  product  components 
identified  in  the  product  architecture  are  defined.  They  are  controlled  as 
part  of  product  and  product  component  integration  and  are  an  integral 
part  of  the  architecture  definition. 

Typical  Work  Products 
1.  Interface  requirements 

Subpractices 

1 .  Identify  interfaces  both  external  to  the  product  and  internal  to  the 
product  (i.e.,  between  functional  partitions  or  objects). 

As  the  design  progresses,  the  product  architecture  will  be  altered  by  technical 
solution  processes,  creating  new  interfaces  between  product  components  and 
components  external  to  the  product. 

Interfaces  with  product-related  lifecycle  processes  should  also  be  identified. 


Examples  of  these  interfaces  include  interfaces  with  test  equipment, 

.  transportation  systems,  support  systems,  and  manufacturing  facilities. 


2.  Develop  the  requirements  for  the  identified  interfaces. 

Refer  to  the  Technical  Solution  process  area  for  more  information 
about  generating  new  interfaces  during  the  design  process. 

Requirements  for  interfaces  are  defined  in  terms  such  as  origination,  destination, 
stimulus,  data  characteristics  for  software,  and  electrical  and  mechanical 
characteristics  for  hardware. 


Analyze  and  Validate  Requirements 

The  requirements  are  analyzed  and  validated,  and  a  definition  of  required 
functionality  is  developed. 

The  specific  practices  of  the  Analyze  and  Validate  Requirements 
specific  goal  support  the  development  of  the  requirements  in  both  the 
Develop  Customer  Requirements  specific  goal  and  the  Develop  Product 
Requirements  specific  goal.  The  specific  practices  associated  with  this 
specific  goal  cover  analyzing  and  validating  the  requirements  with 
respect  to  the  user’s  intended  environment. 

Analyses  are  performed  to  determine  what  impact  the  intended 
operational  environment  will  have  on  the  ability  to  satisfy  the 
stakeholders’  needs,  expectations,  constraints,  and  interfaces. 
Considerations,  such  as  feasibility,  mission  needs,  cost  constraints, 
potential  market  size,  and  acquisition  strategy,  must  all  be  taken  into 
account,  depending  on  the  product  context.  A  definition  of  required 
functionality  is  also  established.  All  specified  usage  modes  for  the 
product  are  considered,  and  a  timeline  analysis  is  generated  for  time- 
critical  sequencing  of  functions. 
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The  objectives  of  the  analyses  are  to  determine  candidate  requirements 
for  product  concepts  that  will  satisfy  stakeholder  needs,  expectations, 
and  constraints;  and  then  to  translate  these  concepts  into  requirements. 
In  parallel  with  this  activity,  the  parameters  that  will  be  used  to  evaluate 
the  effectiveness  of  the  product  are  determined  based  on  customer 
input  and  the  preliminary  product  concept. 

Requirements  are  validated  to  increase  the  probability  that  the  resulting 
product  will  perform  as  intended  in  the  use  environment. 


SP  3.1  Establish  Operational  Concepts  and  Scenarios 

Establish  and  maintain  operational  concepts  and  associated 
scenarios. 


A  scenario  is  typically  a  sequence  of  events  that  might  occur  in  the  use 
of  the  product,  which  is  used  to  make  explicit  some  of  the  needs  of  the 
stakeholders.  In  contrast,  an  operational  concept  for  a  product  usually 
depends  on  both  the  design  solution  and  the  scenario.  For  example,  the 
operational  concept  for  a  satellite-based  communications  product  is 
quite  different  from  one  based  on  landlines.  Since  the  alternative 
solutions  have  not  usually  been  defined  when  preparing  the  initial 
operational  concepts,  conceptual  solutions  are  developed  for  use  when 
analyzing  the  requirements.  The  operational  concepts  are  refined  as 
solution  decisions  are  made  and  lower  level  detailed  requirements  are 
developed. 

Just  as  a  design  decision  for  a  product  may  become  a  requirement  for 
product  components,  the  operational  concept  may  become  the 
scenarios  (requirements)  for  product  components.  Operational  concepts 
and  scenarios  are  evolved  to  facilitate  the  selection  of  product 
component  solutions  that,  when  implemented,  will  satisfy  the  intended 
use  of  the  product.  Operational  concepts  and  scenarios  document  the 
interaction  of  the  product  components  with  the  environment,  users,  and 
other  product  components,  regardless  of  engineering  discipline.  They 
should  be  documented  for  all  modes  and  states  within  operations, 
product  deployment,  delivery,  support  (including  maintenance  and 
sustainment),  training,  and  disposal. 

The  scenarios  may  include  operational  sequences,  provided  those 
sequences  are  an  expression  of  customer  requirements  rather  than 
operational  concepts. 

Typical  Work  Products 

1.  Operational  concept 

2.  Product  or  product  component  installation,  operational, 
maintenance,  and  support  concepts 

3.  Disposal  concepts 
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4.  Use  cases 

5.  Timeline  scenarios 

6.  New  requirements 

Subpractices 

1 .  Develop  operational  concepts  and  scenarios  that  include 
functionality,  performance,  maintenance,  support,  and  disposal  as 
appropriate. 

Identify  and  develop  scenarios,  consistent  with  the  level  of  detail  in  the 
stakeholder  needs,  expectations,  and  constraints  in  which  the  proposed  product 
or  product  component  is  expected  to  operate. 

2.  Define  the  environment  in  which  the  product  or  product  component 
will  operate,  including  boundaries  and  constraints. 

3.  Review  operational  concepts  and  scenarios  to  refine  and  discover 
requirements. 

Operational  concept  and  scenario  development  is  an  iterative  process.  The 
reviews  should  be  held  periodically  to  ensure  that  they  agree  with  the 
requirements.  The  review  may  be  in  the  form  of  a  walkthrough. 

4.  Develop  a  detailed  operational  concept,  as  products  and  product 
components  are  selected,  that  defines  the  interaction  of  the 
product,  the  end  user,  and  the  environment,  and  that  satisfies  the 
operational,  maintenance,  support,  and  disposal  needs. 

SP  3.2  Establish  a  Definition  of  Required  Functionality 

Establish  and  maintain  a  definition  of  required  functionality. 


The  definition  of  functionality,  also  referred  to  as  “functional  analysis,”  is 
the  description  of  what  the  product  is  intended  to  do.  The  definition  of 
functionality  can  include  actions,  sequence,  inputs,  outputs,  or  other 
information  that  communicates  the  manner  in  which  the  product  will  be 
used. 

Functional  analysis  is  not  the  same  as  structured  analysis  in  software 
development  and  does  not  presume  a  functionally  oriented  software 
design.  In  object-oriented  software  design,  it  relates  to  defining  what  are 
called  “services”  or  “methods.”  The  definition  of  functions,  their  logical 
groupings,  and  their  association  with  requirements  is  referred  to  as  a 
functional  architecture.  (See  the  definition  of  “functional  architecture”  in 
the  glossary.) 

Typical  Work  Products 

1.  Functional  architecture 

2.  Activity  diagrams  and  use  cases 
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3.  Object-oriented  analysis  with  services  or  methods  identified 

Subpractices 

1 .  Analyze  and  quantify  functionality  required  by  end  users. 

2.  Analyze  requirements  to  identify  logical  or  functional  partitions 
(e.g.,  subfunctions). 

3.  Partition  requirements  into  groups,  based  on  established  criteria 
(e.g.,  similar  functionality,  performance,  or  coupling),  to  facilitate 
and  focus  the  requirements  analysis. 

4.  Consider  the  sequencing  of  time-critical  functions  both  initially  and 
subsequently  during  product  component  development. 

5.  Allocate  customer  requirements  to  functional  partitions,  objects, 
people,  or  support  elements  to  support  the  synthesis  of  solutions. 

6.  Allocate  functional  and  performance  requirements  to  functions  and 
subfunctions. 


SP  3.3  Analyze  Requirements 

Analyze  requirements  to  ensure  that  they  are  necessary  and 
sufficient. 


In  light  of  the  operational  concept  and  scenarios,  the  requirements  for 
one  level  of  the  product  hierarchy  are  analyzed  to  determine  whether 
they  are  necessary  and  sufficient  to  meet  the  objectives  of  higher  levels 
of  the  product  hierarchy.  The  analyzed  requirements  then  provide  the 
basis  for  more  detailed  and  precise  requirements  for  lower  levels  of  the 
product  hierarchy. 

As  requirements  are  defined,  their  relationship  to  higher  level 
requirements  and  the  higher  level  defined  functionality  must  be 
understood.  One  of  the  other  actions  is  the  determination  of  which  key 
requirements  will  be  used  to  track  progress.  For  instance,  the  weight  of 
a  product  or  size  of  a  software  product  may  be  monitored  through 
development  based  on  its  risk. 

Refer  to  the  Verification  process  area  for  more  information  about 
verification  methods  that  could  be  used  to  support  this  analysis. 

Typical  Work  Products 

1.  Requirements  defects  reports 

2.  Proposed  requirements  changes  to  resolve  defects 

3.  Key  requirements 

4.  Technical  performance  measures 
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Subpractices 

1.  Analyze  stakeholder  needs,  expectations,  constraints,  and  external 
interfaces  to  remove  conflicts  and  to  organize  into  related  subjects. 

2.  Analyze  requirements  to  determine  whether  they  satisfy  the 
objectives  of  higher  level  requirements. 

3.  Analyze  requirements  to  ensure  that  they  are  complete,  feasible, 
realizable,  and  verifiable. 

While  design  determines  the  feasibility  of  a  particular  solution,  this  subpractice 
addresses  knowing  which  requirements  affect  feasibility. 

4.  Identify  key  requirements  that  have  a  strong  influence  on  cost, 
schedule,  functionality,  risk,  or  performance. 

5.  Identify  technical  performance  measures  that  will  be  tracked  during 
the  development  effort. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  use  of  measurements. 

6.  Analyze  operational  concepts  and  scenarios  to  refine  the  customer 
needs,  constraints,  and  interfaces  and  to  discover  new 
requirements. 

This  analysis  may  result  in  more  detailed  operational  concepts  and  scenarios  as 
well  as  supporting  the  derivation  of  new  requirements. 


SP  3.4  Analyze  Requirements  to  Achieve  Balance 

Analyze  requirements  to  balance  stakeholder  needs  and 
constraints. 


Stakeholder  needs  and  constraints  can  address  cost,  schedule, 
performance,  functionality,  reusable  components,  maintainability,  or 
risk. 

Typical  Work  Products 

1 .  Assessment  of  risks  related  to  requirements 
Subpractices 

1.  Use  proven  models,  simulations,  and  prototyping  to  analyze  the 
balance  of  stakeholder  needs  and  constraints. 

Results  of  the  analyses  can  be  used  to  reduce  the  cost  of  the  product  and  the  risk 
in  developing  the  product. 

2.  Perform  a  risk  assessment  on  the  requirements  and  functional 
architecture. 
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Refer  to  the  Risk  Management  process  area  for  information  about 
performing  a  risk  assessment  on  customer  and  product 
requirements  and  the  functional  architecture. 

3.  Examine  product  lifecycle  concepts  for  impacts  of  requirements  on 
risks. 


SP  3.5  Validate  Requirements 

Validate  requirements  to  ensure  the  resulting  product  will 
perform  as  intended  in  the  user's  environment. 


Requirements  validation  is  performed  early  in  the  development  effort 
with  end  users  to  gain  confidence  that  the  requirements  are  capable  of 
guiding  a  development  that  results  in  successful  final  validation.  This 
activity  should  be  integrated  with  risk  management  activities.  Mature 
organizations  will  typically  perform  requirements  validation  in  a  more 
sophisticated  way  using  multiple  techniques  and  will  broaden  the  basis 
of  the  validation  to  include  other  stakeholder  needs  and  expectations. 


Examples  of  techniques  used  for  requirements  validation  include  the  following: 

•  Analysis 

•  Simulations 

•  Prototyping 

•  Demonstrations 


Typical  Work  Products 

1 .  Record  of  analysis  methods  and  results 

Subpractices 

1 .  Analyze  the  requirements  to  determine  the  risk  that  the  resulting 
product  will  not  perform  appropriately  in  its  intended-use 
environment. 

2.  Explore  the  adequacy  and  completeness  of  requirements  by 
developing  product  representations  (e.g.,  prototypes,  simulations, 
models,  scenarios,  and  storyboards)  and  by  obtaining  feedback 
about  them  from  relevant  stakeholders. 

Refer  to  the  Validation  process  area  for  information  about 
preparing  for  and  performing  validation  on  products  and  product 
components. 

3.  Assess  the  design  as  it  matures  in  the  context  of  the  requirements 
validation  environment  to  identify  validation  issues  and  expose 
unstated  needs  and  customer  requirements. 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1 

Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  requirements  development 
process  to  develop  work  products  and  provide  services  to 
achieve  the  specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  requirements  development  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  collecting 
stakeholder  needs,  formulating  product  and  product  component 
requirements,  and  analyzing  and  validating  those  requirements. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
requirements  development  process. 


Elaboration: 

This  plan  for  performing  the  requirements  development  process  can  be 
part  of  (or  referenced  by)  the  project  plan  as  described  in  the  Project 
Planning  process  area. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  requirements 
development  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 


Elaboration: 

Special  expertise  in  the  application  domain,  methods  for  eliciting 
stakeholder  needs,  and  methods  and  tools  for  specifying  and  analyzing 
customer,  product,  and  product  component  requirements  may  be 
required. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Requirements  specification  tools 

•  Simulators  and  modeling  tools 

•  Prototyping  tools 

•  Scenario  definition  and  management  tools 

•  Requirements  tracking  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  requirements  development  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  requirements 
development  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 

I  •  Application  domain 

I  •  Requirements  definition  and  analysis 

:  •  Requirements  elicitation 

|  •  Requirements  specification  and  modeling 

•  Requirements  tracking 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  requirements 
development  process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Customer  requirements 

I  •  Functional  architecture 

|  •  Product  and  product  component  requirements 

•  Interface  requirements 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
requirements  development  process  as  planned. 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Reviewing  the  adequacy  of  requirements  in  meeting  needs,  expectations, 
constraints,  and  interfaces 

•  Establishing  operational  concepts  and  scenarios 

•  Assessing  the  adequacy  of  requirements 

•  Establishing  product  and  product  component  requirements 

•  Assessing  product  cost,  schedule,  and  risk 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  requirements  development  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Cost,  schedule,  and  effort  expended  for  rework 

•  Defect  density  of  requirements  specifications 

•  Schedule  for  activities  to  develop  a  set  of  requirements. 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  requirements 
development  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

|  •  Collecting  stakeholder  needs 

|  •  Formulating  product  and  product  component  requirements 

i 

:  •  Analyzing  and  validating  product  and  product  component  requirements 

:  Examples  of  work  products  reviewed  include  the  following: 

:  •  Product  requirements 
:  •  Product  component  requirements 
:  •  Interface  requirements 
•  Functional  architecture 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  requirements 
development  process  with  higher  level  management  and 
resolve  issues. 

Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
requirements  development  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  requirements  development  process  to  support 
the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 


406 


Requirements  Development  (RD) 


CMMI  for  Development 
Version  1.2 

Elaboration: 

:  Examples  of  work  products,  measures,  measurement  results,  and  improvement 
:  information  include  the  following: 

i  •  List  of  the  requirements  for  a  product  that  are  found  to  be  ambiguous 
i  •  Number  of  requirements  introduced  at  each  phase  of  the  project  lifecycle 
•  Lessons  learned  from  the  requirements  allocation  process 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
requirements  development  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  requirements  development  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  requirements 
development  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  requirements  development  process. 
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REQUIREMENTS  MANAGEMENT 


An  Engineering  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Requirements  Management  (REQM)  is  to  manage  the 
requirements  of  the  project’s  products  and  product  components  and  to 
identify  inconsistencies  between  those  requirements  and  the  project’s 
plans  and  work  products. 


Introductory  Notes 


Requirements  management  processes  manage  all  requirements 
received  or  generated  by  the  project,  including  both  technical  and 
nontechnical  requirements  as  well  as  those  requirements  levied  on  the 
project  by  the  organization.  In  particular,  if  the  Requirements 
Development  process  area  is  implemented,  its  processes  will  generate 
product  and  product  component  requirements  that  will  also  be  managed 
by  the  requirements  management  processes.  Throughout  the  process 
areas,  where  we  use  the  terms  product  and  product  component,  their 
intended  meanings  also  encompass  services  and  their  components. 
When  the  Requirements  Management,  Requirements  Development, 
and  Technical  Solution  process  areas  are  all  implemented,  their 
associated  processes  may  be  closely  tied  and  be  performed 
concurrently. 

The  project  takes  appropriate  steps  to  ensure  that  the  agreed-on  set  of 
requirements  is  managed  to  support  the  planning  and  execution  needs 
of  the  project.  When  a  project  receives  requirements  from  an  approved 
requirements  provider,  the  requirements  are  reviewed  with  the 
requirements  provider  to  resolve  issues  and  prevent  misunderstanding 
before  the  requirements  are  incorporated  into  the  project’s  plans.  Once 
the  requirements  provider  and  the  requirements  receiver  reach  an 
agreement,  commitment  to  the  requirements  is  obtained  from  the 
project  participants.  The  project  manages  changes  to  the  requirements 
as  they  evolve  and  identifies  any  inconsistencies  that  occur  among  the 
plans,  work  products,  and  requirements. 

Part  of  the  management  of  requirements  is  to  document  requirements 
changes  and  rationale  and  to  maintain  bidirectional  traceability  between 
source  requirements  and  all  product  and  product  component 
requirements  (See  the  definition  of  “bidirectional  traceability”  in  the 
glossary.) 
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All  development  projects  have  requirements.  In  the  case  of  a  project 
that  is  focused  on  maintenance  activities,  the  changes  to  the  product  or 
product  components  are  based  on  changes  to  the  existing 
requirements,  design,  or  implementation.  The  requirements  changes,  if 
any,  might  be  documented  in  change  requests  from  the  customer  or 
users,  or  they  might  take  the  form  of  new  requirements  received  from 
the  requirements  development  process.  Regardless  of  their  source  or 
form,  the  maintenance  activities  that  are  driven  by  changes  to 
requirements  are  managed  accordingly. 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  transforming  stakeholder  needs  into  product 
requirements  and  deciding  how  to  allocate  or  distribute  requirements 
among  the  product  components. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
transforming  requirements  into  technical  solutions. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
how  project  plans  reflect  requirements  and  need  to  be  revised  as 
requirements  change. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  baselines  and  controlling  changes  to  configuration 
documentation  for  requirements. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  and  controlling  the  activities  and  work 
products  that  are  based  on  the  requirements  and  taking  appropriate 
corrective  action. 


Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  handling  risks  associated  with  requirements. 


Specific  Goal  and  Practice  Summary 


SG  1  Manage  Requirements 

SP  1.1  Obtain  an  Understanding  of  Requirements 

SP  1 .2  Obtain  Commitment  to  Requirements 

SP1.3  Manage  Requirements  Changes 

SP  1.4  Maintain  Bidirectional  Traceability  of  Requirements 

SP  1 .5  Identify  Inconsistencies  Between  Project  Work  and  Requirements 
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Specific  Practices  by  Goal 


SG  1  Manage  Requirements 

Requirements  are  managed  and  inconsistencies  with  project  plans  and 
work  products  are  identified. 

The  project  maintains  a  current  and  approved  set  of  requirements  over 
the  life  of  the  project  by  doing  the  following: 

•  Managing  all  changes  to  the  requirements 

•  Maintaining  the  relationships  among  the  requirements,  the  project 
plans,  and  the  work  products 

•  Identifying  inconsistencies  among  the  requirements,  the  project 
plans,  and  the  work  products 

•  Taking  corrective  action 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
determining  the  feasibility  of  the  requirements. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  ensuring  that  the  requirements  reflect  the  needs  and 
expectations  of  the  customer. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

SP  1.1  Obtain  an  Understanding  of  Requirements 

Develop  an  understanding  with  the  requirements  providers  on 
the  meaning  of  the  requirements. 


As  the  project  matures  and  requirements  are  derived,  all  activities  or 
disciplines  will  receive  requirements.  To  avoid  requirements  creep, 
criteria  are  established  to  designate  appropriate  channels,  or  official 
sources,  from  which  to  receive  requirements.  The  receiving  activities 
conduct  analyses  of  the  requirements  with  the  requirements  provider  to 
ensure  that  a  compatible,  shared  understanding  is  reached  on  the 
meaning  of  the  requirements.  The  result  of  this  analysis  and  dialog  is  an 
agreed-to  set  of  requirements. 

Typical  Work  Products 

1 .  Lists  of  criteria  for  distinguishing  appropriate  requirements 
providers 

2.  Criteria  for  evaluation  and  acceptance  of  requirements 

3.  Results  of  analyses  against  criteria 

4.  An  agreed-to  set  of  requirements 
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Subpractices 

1 .  Establish  criteria  for  distinguishing  appropriate  requirements 
providers. 

2.  Establish  objective  criteria  for  the  evaluation  and  acceptance  of 
requirements. 

Lack  of  evaluation  and  acceptance  criteria  often  results  in  inadequate  verification, 
costly  rework,  or  customer  rejection. 

Examples  of  evaluation  and  acceptance  criteria  include  the  following: 

|  •  Clearly  and  properly  stated 
:  •  Complete 

i  •  Consistent  with  each  other 
|  •  Uniquely  identified 
i  •  Appropriate  to  implement 
:  •  Verifiable  (testable) 

•  Traceable 

3.  Analyze  requirements  to  ensure  that  the  established  criteria  are 
met. 

4.  Reach  an  understanding  of  the  requirements  with  the  requirements 
provider  so  that  the  project  participants  can  commit  to  them. 

SP  1.2  Obtain  Commitment  to  Requirements 

Obtain  commitment  to  the  requirements  from  the  project 
participants. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  the  commitments  made. 


IPPD  Addition 

When  integrated  teams  are  formed,  the  project  participants  are  the 
integrated  teams  and  their  members.  Commitment  to  the  requirement  for 
interacting  with  other  integrated  teams  is  as  important  for  each  integrated 
team  as  its  commitments  to  product  and  other  project  requirements. 


Whereas  the  previous  specific  practice  dealt  with  reaching  an 
understanding  with  the  requirements  providers,  this  specific  practice 
deals  with  agreements  and  commitments  among  those  who  have  to 
carry  out  the  activities  necessary  to  implement  the  requirements. 
Requirements  evolve  throughout  the  project,  especially  as  described  by 
the  specific  practices  of  the  Requirements  Development  process  area 
and  the  Technical  Solution  process  area.  As  the  requirements  evolve, 
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this  specific  practice  ensures  that  project  participants  commit  to  the 
current,  approved  requirements  and  the  resulting  changes  in  project 
plans,  activities,  and  work  products. 


Typical  Work  Products 

1 .  Requirements  impact  assessments 

2.  Documented  commitments  to  requirements  and  requirements 
changes 

Subpractices 

1 .  Assess  the  impact  of  requirements  on  existing  commitments. 

The  impact  on  the  project  participants  should  be  evaluated  when  the  requirements 
change  or  at  the  start  of  a  new  requirement. 

2.  Negotiate  and  record  commitments. 

Changes  to  existing  commitments  should  be  negotiated  before  project  participants 
commit  to  the  requirement  or  requirement  change. 

SP  1.3  Manage  Requirements  Changes 

Manage  changes  to  the  requirements  as  they  evolve  during  the 
project. 


Refer  to  the  Configuration  Management  process  area  for  more 
information  about  maintaining  and  controlling  the  requirements  baseline 
and  on  making  the  requirements  and  change  data  available  to  the 
project. 

During  the  project,  requirements  change  for  a  variety  of  reasons.  As 
needs  change  and  as  work  proceeds,  additional  requirements  are 
derived  and  changes  may  have  to  be  made  to  the  existing 
requirements.  It  is  essential  to  manage  these  additions  and  changes 
efficiently  and  effectively.  To  effectively  analyze  the  impact  of  the 
changes,  it  is  necessary  that  the  source  of  each  requirement  is  known 
and  the  rationale  for  any  change  is  documented.  The  project  manager 
may,  however,  want  to  track  appropriate  measures  of  requirements 
volatility  to  judge  whether  new  or  revised  controls  are  necessary. 

Typical  Work  Products 

1.  Requirements  status 

2.  Requirements  database 

3.  Requirements  decision  database 
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Subpractices 

1 .  Document  all  requirements  and  requirements  changes  that  are 
given  to  or  generated  by  the  project. 

2.  Maintain  the  requirements  change  history  with  the  rationale  for  the 
changes. 

Maintaining  the  change  history  helps  track  requirements  volatility. 

3.  Evaluate  the  impact  of  requirement  changes  from  the  standpoint  of 
relevant  stakeholders. 

4.  Make  the  requirements  and  change  data  available  to  the  project. 


SP  1.4  Maintain  Bidirectional  Traceability  of  Requirements 

Maintain  bidirectional  traceability  among  the  requirements  and 
work  products. 


The  intent  of  this  specific  practice  is  to  maintain  the  bidirectional 
traceability  of  requirements  for  each  level  of  product  decomposition. 
(See  the  definition  of  “bidirectional  traceability’’  in  the  glossary.)  When 
the  requirements  are  managed  well,  traceability  can  be  established 
from  the  source  requirement  to  its  lower  level  requirements  and  from 
the  lower  level  requirements  back  to  their  source.  Such  bidirectional 
traceability  helps  determine  that  all  source  requirements  have  been 
completely  addressed  and  that  all  lower  level  requirements  can  be 
traced  to  a  valid  source. 

Requirements  traceability  can  also  cover  the  relationships  to  other 
entities  such  as  intermediate  and  final  work  products,  changes  in  design 
documentation,  and  test  plans.  The  traceability  can  cover  horizontal 
relationships,  such  as  across  interfaces,  as  well  as  vertical 
relationships.  Traceability  is  particularly  needed  in  conducting  the 
impact  assessment  of  requirements  changes  on  the  project's  activities 
and  work  products. 

Typical  Work  Products 

1 .  Requirements  traceability  matrix 

2.  Requirements  tracking  system 
Subpractices 

1 .  Maintain  requirements  traceability  to  ensure  that  the  source  of 
lower  level  (derived)  requirements  is  documented. 

2.  Maintain  requirements  traceability  from  a  requirement  to  its  derived 
requirements  and  allocation  to  functions,  interfaces,  objects, 
people,  processes,  and  work  products. 

3.  Generate  the  requirements  traceability  matrix. 
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SP  1.5  Identify  Inconsistencies  Between  Project  Work  and  Requirements 

Identify  inconsistencies  between  the  project  plans  and  work 
products  and  the  requirements. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  plans  and  work 
products  for  consistency  with  requirements  and  taking  corrective 
actions  when  necessary. 

This  specific  practice  finds  the  inconsistencies  between  the 
requirements  and  the  project  plans  and  work  products  and  initiates  the 
corrective  action  to  fix  them. 

Typical  Work  Products 

1.  Documentation  of  inconsistencies  including  sources,  conditions, 
and  rationale 

2.  Corrective  actions 
Subpractices 

1 .  Review  the  project’s  plans,  activities,  and  work  products  for 
consistency  with  the  requirements  and  the  changes  made  to  them. 

2.  Identify  the  source  of  the  inconsistency  and  the  rationale. 

3.  Identify  changes  that  need  to  be  made  to  the  plans  and  work 
products  resulting  from  changes  to  the  requirements  baseline. 

4.  Initiate  corrective  actions. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  requirements  management 
process  to  develop  work  products  and  provide  services  to 
achieve  the  specific  goals  of  the  process  area. 
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GG  2 


Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  requirements  management  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  managing 
requirements  and  identifying  inconsistencies  between  the  requirements 
and  the  project  plans  and  work  products. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the 
requirements  management  process. 


Elaboration: 

This  plan  for  performing  the  requirements  management  process  can  be 
part  of  (or  referenced  by)  the  project  plan  as  described  in  the  Project 
Planning  process  area. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  requirements 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools: 

•  Requirements  tracking  tools 

•  Traceability  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  requirements  management  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  requirements 
management  process  as  needed. 
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Elaboration: 

:  Examples  of  training  topics  include  the  following: 

I  •  Application  domain 

I  •  Requirements  definition,  analysis,  review,  and  management 
|  •  Requirements  management  tools 

j  •  Configuration  management 

•  Negotiation  and  conflict  resolution 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  requirements 
management  process  under  appropriate  levels  of  control. 

Elaboration: 

;  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Requirements 
•  Requirements  traceability  matrix 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the 
requirements  management  process  as  planned. 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Resolving  issues  on  the  understanding  of  the  requirements 

•  Assessing  the  impact  of  requirements  changes 

•  Communicating  the  bidirectional  traceability 

•  Identifying  inconsistencies  among  project  plans,  work  products,  and  requirements 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  requirements  management  process 
against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 
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Elaboration: 

Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
:  the  following: 

:  •  Requirements  volatility  (percentage  of  requirements  changed) 
i  •  Schedule  for  coordination  of  requirements 
•  Schedule  for  analysis  of  a  proposed  requirements  change 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  requirements 
management  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

Elaboration: 

:  Examples  of  activities  reviewed  include  the  following: 
i  •  Managing  requirements 

•  Identifying  inconsistencies  among  project  plans,  work  products,  and  requirements 

Examples  of  work  products  reviewed  include  the  following: 
j  •  Requirements 

•  Requirements  traceability  matrix 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  requirements 
management  process  with  higher  level  management  and 
resolve  issues. 


Elaboration: 

Proposed  changes  to  commitments  to  be  made  external  to  the 
organization  are  reviewed  with  higher  level  management  to  ensure  that 
all  commitments  can  be  accomplished. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 
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Continuous/Maturity  Levels  3  -  5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined 
requirements  management  process. 

GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  requirements  management  process  to  support 
the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Requirements  traceability  matrix 

•  Number  of  unfunded  requirements  changes  after  baselining 

•  Lessons  learned  in  resolving  ambiguous  requirements 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
requirements  management  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  requirements  management  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 
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Continuous  Only 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  requirements 
management  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  requirements  management  process. 
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RISK  MANAGEMENT 


A  Project  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Risk  Management  (RSKM)  is  to  identify  potential 
problems  before  they  occur  so  that  risk-handling  activities  can  be 
planned  and  invoked  as  needed  across  the  life  of  the  product  or  project 
to  mitigate  adverse  impacts  on  achieving  objectives. 


Introductory  Notes 


Risk  management  is  a  continuous,  forward-looking  process  that  is  an 
important  part  of  management.  Risk  management  should  address 
issues  that  could  endanger  achievement  of  critical  objectives.  A 
continuous  risk  management  approach  is  applied  to  effectively 
anticipate  and  mitigate  the  risks  that  may  have  a  critical  impact  on  the 
project. 

Effective  risk  management  includes  early  and  aggressive  risk 
identification  through  the  collaboration  and  involvement  of  relevant 
stakeholders,  as  described  in  the  stakeholder  involvement  plan 
addressed  in  the  Project  Planning  process  area.  Strong  leadership 
across  all  relevant  stakeholders  is  needed  to  establish  an  environment 
for  the  free  and  open  disclosure  and  discussion  of  risk. 

Risk  management  must  consider  both  internal  and  external  sources  for 
cost,  schedule,  and  performance  risk  as  well  as  other  risks.  Early  and 
aggressive  detection  of  risk  is  important  because  it  is  typically  easier, 
less  costly,  and  less  disruptive  to  make  changes  and  correct  work 
efforts  during  the  earlier,  rather  than  the  later,  phases  of  the  project. 

Risk  management  can  be  divided  into  three  parts:  defining  a  risk 
management  strategy;  identifying  and  analyzing  risks;  and  handling 
identified  risks,  including  the  implementation  of  risk  mitigation  plans 
when  needed. 

As  represented  in  the  Project  Planning  and  Project  Monitoring  and 
Control  process  areas,  organizations  may  initially  focus  simply  on  risk 
identification  for  awareness,  and  react  to  the  realization  of  these  risks 
as  they  occur.  The  Risk  Management  process  area  describes  an 
evolution  of  these  specific  practices  to  systematically  plan,  anticipate, 
and  mitigate  risks  to  proactively  minimize  their  impact  on  the  project. 
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Although  the  primary  emphasis  of  the  Risk  Management  process  area 
is  on  the  project,  the  concepts  can  also  be  applied  to  manage 
organizational  risks. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identification  of  project  risks  and  planning  for  involvement  of  relevant 
stakeholders. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  risks. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  to  evaluate 
alternatives  for  selection  and  mitigation  of  identified  risks. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Risk  Management 

SP  1 .1  Determine  Risk  Sources  and  Categories 
SP  1 .2  Define  Risk  Parameters 
SP  1 .3  Establish  a  Risk  Management  Strategy 
SG  2  Identify  and  Analyze  Risks 
SP  2.1  Identify  Risks 

SP  2.2  Evaluate,  Categorize,  and  Prioritize  Risks 
SG  3  Mitigate  Risks 

SP  3.1  Develop  Risk  Mitigation  Plans 
SP  3.2  Implement  Risk  Mitigation  Plans 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Risk  Management 

Preparation  for  risk  management  is  conducted. 

Preparation  is  conducted  by  establishing  and  maintaining  a  strategy  for 
identifying,  analyzing,  and  mitigating  risks.  This  is  typically  documented 
in  a  risk  management  plan.  The  risk  management  strategy  addresses 
the  specific  actions  and  management  approach  used  to  apply  and 
control  the  risk  management  program.  This  includes  identifying  the 
sources  of  risk;  the  scheme  used  to  categorize  risks;  and  the 
parameters  used  to  evaluate,  bound,  and  control  risks  for  effective 
handling. 

SP  1.1  Determine  Risk  Sources  and  Categories 

Determine  risk  sources  and  categories. 


Identification  of  risk  sources  provides  a  basis  for  systematically 
examining  changing  situations  overtime  to  uncover  circumstances  that 
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impact  the  ability  of  the  project  to  meet  its  objectives.  Risk  sources  are 
both  internal  and  external  to  the  project.  As  the  project  progresses, 
additional  sources  of  risk  may  be  identified.  Establishing  categories  for 
risks  provides  a  mechanism  for  collecting  and  organizing  risks  as  well 
as  ensuring  appropriate  scrutiny  and  management  attention  for  those 
risks  that  can  have  more  serious  consequences  on  meeting  project 
objectives. 

Typical  Work  Products 

1 .  Risk  source  lists  (external  and  internal) 

2.  Risk  categories  list 

Subpractices 

1 .  Determine  risk  sources. 

Risk  sources  are  the  fundamental  drivers  that  cause  risks  within  a  project  or 
organization.  There  are  many  sources  of  risks,  both  internal  and  external,  to  a 
project.  Risk  sources  identify  common  areas  where  risks  may  originate.  Typical 
internal  and  external  risk  sources  include  the  following: 

•  Uncertain  requirements 

•  Unprecedented  efforts— estimates  unavailable 

•  Infeasible  design 

•  Unavailable  technology 

•  Unrealistic  schedule  estimates  or  allocation 

•  Inadequate  staffing  and  skills 

•  Cost  or  funding  issues 

•  Uncertain  or  inadequate  subcontractor  capability 

•  Uncertain  or  inadequate  vendor  capability 

•  Inadequate  communication  with  actual  or  potential  customers  or  with  their 
representatives 

•  Disruptions  to  continuity  of  operations 

Many  of  these  sources  of  risk  are  often  accepted  without  adequate  planning.  Early 
identification  of  both  internal  and  external  sources  of  risk  can  lead  to  early 
identification  of  risks.  Risk  mitigation  plans  can  then  be  implemented  early  in  the 
project  to  preclude  occurrence  of  the  risks  or  reduce  the  consequences  of  their 
occurrence. 

2.  Determine  risk  categories. 

Risk  categories  reflect  the  “bins"  for  collecting  and  organizing  risks.  A  reason  for 
identifying  risk  categories  is  to  help  in  the  future  consolidation  of  the  activities  in 
the  risk  mitigation  plans. 
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The  following  factors  may  be  considered  when  determining  risk  categories: 

i  •  The  phases  of  the  project’s  lifecycle  model  (e.g.,  requirements,  design, 

:  manufacturing,  test  and  evaluation,  delivery,  and  disposal) 

i  •  The  types  of  processes  used 

j  •  The  types  of  products  used 

:  •  Program  management  risks  (e.g.,  contract  risks,  budget/cost  risks,  schedule  risks, 
resources  risks,  performance  risks,  and  supportability  risks) 


A  risk  taxonomy  can  be  used  to  provide  a  framework  for  determining  risk  sources 
and  categories. 


SP  1.2  Define  Risk  Parameters 

Define  the  parameters  used  to  analyze  and  categorize  risks, 
and  the  parameters  used  to  control  the  risk  management  effort. 


Parameters  for  evaluating,  categorizing,  and  prioritizing  risks  include 
the  following: 

•  Risk  likelihood  (i.e.,  probability  of  risk  occurrence) 

•  Risk  consequence  (i.e.,  impact  and  severity  of  risk  occurrence) 

•  Thresholds  to  trigger  management  activities 

Risk  parameters  are  used  to  provide  common  and  consistent  criteria  for 
comparing  the  various  risks  to  be  managed.  Without  these  parameters, 
it  would  be  very  difficult  to  gauge  the  severity  of  the  unwanted  change 
caused  by  the  risk  and  to  prioritize  the  necessary  actions  required  for 
risk  mitigation  planning. 

Typical  Work  Products 

1.  Risk  evaluation,  categorization,  and  prioritization  criteria 

2.  Risk  management  requirements  (e.g.,  control  and  approval  levels, 
and  reassessment  intervals) 

Subpractices 

1 .  Define  consistent  criteria  for  evaluating  and  quantifying  risk 
likelihood  and  severity  levels. 

Consistently  used  criteria  (e.g.,  the  bounds  on  the  likelihood  and  severity  levels) 
allow  the  impacts  of  different  risks  to  be  commonly  understood,  to  receive  the 
appropriate  level  of  scrutiny,  and  to  obtain  the  management  attention  warranted. 

In  managing  dissimilar  risks  (e.g.,  personnel  safety  versus  environmental 
pollution),  it  is  important  to  ensure  consistency  in  end  result  (e.g.,  a  high  risk  of 
environmental  pollution  is  as  important  as  a  high  risk  to  personnel  safety). 

2.  Define  thresholds  for  each  risk  category. 
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For  each  risk  category,  thresholds  can  be  established  to  determine  acceptability 
or  unacceptability  of  risks,  prioritization  of  risks,  or  triggers  for  management 
action. 


Examples  of  thresholds  include  the  following: 

•  Project-wide  thresholds  could  be  established  to  involve  senior  management  when 
product  costs  exceed  10  percent  of  the  target  cost  or  when  Cost  Performance 
Indexes  (CPIs)  fall  below  0.95. 

•  Schedule  thresholds  could  be  established  to  involve  senior  management  when 
Schedule  Performance  Indexes  (SPIs)  fall  below  0.95. 

•  Performance  thresholds  could  be  set  to  involve  senior  management  when 
specified  key  items  (e.g.,  processor  utilization  or  average  response  times)  exceed 
125  percent  of  the  intended  design. 


These  may  be  refined  later,  for  each  identified  risk,  to  establish  points  at  which 
more  aggressive  risk  monitoring  is  employed  or  to  signal  the  implementation  of 
risk  mitigation  plans. 

3.  Define  bounds  on  the  extent  to  which  thresholds  are  applied 
against  or  within  a  category. 

There  are  few  limits  to  which  risks  can  be  assessed  in  either  a  quantitative  or 
qualitative  fashion.  Definition  of  bounds  (or  boundary  conditions)  can  be  used  to 
help  scope  the  extent  of  the  risk  management  effort  and  avoid  excessive  resource 
expenditures.  Bounds  may  include  exclusion  of  a  risk  source  from  a  category. 
These  bounds  can  also  exclude  any  condition  that  occurs  less  than  a  given 
frequency. 


SP  1.3  Establish  a  Risk  Management  Strategy 

Establish  and  maintain  the  strategy  to  be  used  for  risk 
management. 


A  comprehensive  risk  management  strategy  addresses  items  such  as 

the  following: 

•  The  scope  of  the  risk  management  effort 

•  Methods  and  tools  to  be  used  for  risk  identification,  risk  analysis, 
risk  mitigation,  risk  monitoring,  and  communication 

•  Project-specific  sources  of  risks 

•  How  these  risks  are  to  be  organized,  categorized,  compared,  and 
consolidated 

•  Parameters,  including  likelihood,  consequence,  and  thresholds,  for 
taking  action  on  identified  risks 

•  Risk  mitigation  techniques  to  be  used,  such  as  prototyping,  piloting, 
simulation,  alternative  designs,  or  evolutionary  development 

•  Definition  of  risk  measures  to  monitor  the  status  of  the  risks 

•  Time  intervals  for  risk  monitoring  or  reassessment 


424 


Risk  Management  (RSKM) 


CMMI  for  Development 
Version  1.2 


The  risk  management  strategy  should  be  guided  by  a  common  vision  of 
success  that  describes  the  desired  future  project  outcomes  in  terms  of 
the  product  that  is  delivered,  its  cost,  and  its  fitness  for  the  task.  The 
risk  management  strategy  is  often  documented  in  an  organizational  or  a 
project  risk  management  plan.  The  risk  management  strategy  is 
reviewed  with  relevant  stakeholders  to  promote  commitment  and 
understanding. 

Typical  Work  Products 

1 .  Project  risk  management  strategy 


SG  2  Identify  and  Analyze  Risks 

Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

The  degree  of  risk  impacts  the  resources  assigned  to  handle  an 
identified  risk  and  the  determination  of  when  appropriate  management 
attention  is  required. 

Analyzing  risks  entails  identifying  risks  from  the  internal  and  external 
sources  identified  and  then  evaluating  each  identified  risk  to  determine 
its  likelihood  and  consequences.  Categorization  of  the  risk,  based  on  an 
evaluation  against  the  established  risk  categories  and  criteria 
developed  for  the  risk  management  strategy,  provides  the  information 
needed  for  risk  handling.  Related  risks  may  be  grouped  for  efficient 
handling  and  effective  use  of  risk  management  resources. 


SP  2.1  Identify  Risks 

Identify  and  document  the  risks. 


IPPD  Addition 

The  particular  risks  associated  with  conducting  the  project  using  integrated 
teams  should  be  considered,  such  as  risks  associated  with  loss  of  inter¬ 
team  or  intra-team  coordination. 


The  identification  of  potential  issues,  hazards,  threats,  and 
vulnerabilities  that  could  negatively  affect  work  efforts  or  plans  is  the 
basis  for  sound  and  successful  risk  management.  Risks  must  be 
identified  and  described  in  an  understandable  way  before  they  can  be 
analyzed  and  managed  properly.  Risks  are  documented  in  a  concise 
statement  that  includes  the  context,  conditions,  and  consequences  of 
risk  occurrence. 

Risk  identification  should  be  an  organized,  thorough  approach  to  seek 
out  probable  or  realistic  risks  in  achieving  objectives.  To  be  effective, 
risk  identification  should  not  be  an  attempt  to  address  every  possible 
event  regardless  of  how  highly  improbable  it  may  be.  Use  of  the 
categories  and  parameters  developed  in  the  risk  management  strategy, 
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along  with  the  identified  sources  of  risk,  can  provide  the  discipline  and 
streamlining  appropriate  to  risk  identification.  The  identified  risks  form  a 
baseline  to  initiate  risk  management  activities.  The  list  of  risks  should 
be  reviewed  periodically  to  reexamine  possible  sources  of  risk  and 
changing  conditions  to  uncover  sources  and  risks  previously  overlooked 
or  nonexistent  when  the  risk  management  strategy  was  last  updated. 

Risk  identification  activities  focus  on  the  identification  of  risks,  not 
placement  of  blame.  The  results  of  risk  identification  activities  are  not 
used  by  management  to  evaluate  the  performance  of  individuals. 

There  are  many  methods  for  identifying  risks.  Typical  identification 
methods  include  the  following: 

•  Examine  each  element  of  the  project  work  breakdown  structure  to 
uncover  risks. 

•  Conduct  a  risk  assessment  using  a  risk  taxonomy. 

•  Interview  subject  matter  experts. 

•  Review  risk  management  efforts  from  similar  products. 

•  Examine  lessons-learned  documents  or  databases. 

•  Examine  design  specifications  and  agreement  requirements. 

Typical  Work  Products 

1.  List  of  identified  risks,  including  the  context,  conditions,  and 
consequences  of  risk  occurrence 

Subpractices 

1.  Identify  the  risks  associated  with  cost,  schedule,  and  performance. 

Cost,  schedule,  and  performance  risks  should  be  examined  to  the  extent  that  they 
impact  project  objectives.  There  may  be  potential  risks  discovered  that  are  outside 
the  scope  of  the  project’s  objectives  but  vital  to  customer  interests.  For  example, 
the  risks  in  development  costs,  product  acquisition  costs,  cost  of  spare  (or 
replacement)  products,  and  product  disposition  (or  disposal)  costs  have  design 
implications.  The  customer  may  not  have  considered  the  full  cost  of  supporting  a 
fielded  product  or  using  a  delivered  service.  The  customer  should  be  informed  of 
such  risks,  but  actively  managing  those  risks  may  not  be  necessary.  The 
mechanisms  for  making  such  decisions  should  be  examined  at  project  and 
organization  levels  and  put  in  place  if  deemed  appropriate,  especially  for  risks  that 
impact  the  ability  to  verify  and  validate  the  product. 

In  addition  to  the  cost  risks  identified  above,  other  cost  risks  may  include  those 
associated  with  funding  levels,  funding  estimates,  and  distributed  budgets. 

Schedule  risks  may  include  risks  associated  with  planned  activities,  key  events, 
and  milestones. 
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Performance  risks  may  include  risks  associated  with  the  following: 

•  Requirements 

•  Analysis  and  design 

•  Application  of  new  technology 

•  Physical  size 

•  Shape 

•  Weight 

•  Manufacturing  and  fabrication 

•  Functional  performance  and  operation 

•  Verification 

•  Validation 

•  Performance  maintenance  attributes 

Performance  maintenance  attributes  are  those  characteristics  that  enable  an  in- 
use  product  or  service  to  provide  originally  required  performance,  such  as 
maintaining  safety  and  security  performance. 

There  are  other  risks  that  do  not  fall  into  cost,  schedule,  or  performance 
categories. 

Examples  of  these  other  risks  include  the  following: 

•  Risks  associated  with  strikes 

•  Diminishing  sources  of  supply 

•  Technology  cycle  time 

•  Competition 


2.  Review  environmental  elements  that  may  impact  the  project. 

Risks  to  a  project  that  frequently  are  missed  include  those  supposedly  outside  the 
scope  of  the  project  (i.e.,  the  project  does  not  control  whether  they  occur  but  can 
mitigate  their  impact),  such  as  weather,  natural  or  manmade  disasters  that  affect 
continuity  of  operations,  political  changes,  and  telecommunications  failures. 

3.  Review  all  elements  of  the  work  breakdown  structure  as  part  of 
identifying  risks  to  help  ensure  that  all  aspects  of  the  work  effort 
have  been  considered. 

4.  Review  all  elements  of  the  project  plan  as  part  of  identifying  risks  to 
help  ensure  that  all  aspects  of  the  project  have  been  considered. 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  identifying  project  risks. 
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5.  Document  the  context,  conditions,  and  potential  consequences  of 
the  risk. 

Risks  statements  are  typically  documented  in  a  standard  format  that  contains  the 
risk  context,  conditions,  and  consequences  of  occurrence.  The  risk  context 
provides  additional  information  such  that  the  intent  of  the  risk  can  be  easily 
understood.  In  documenting  the  context  of  the  risk,  consider  the  relative  time 
frame  of  the  risk,  the  circumstances  or  conditions  surrounding  the  risk  that  has 
brought  about  the  concern,  and  any  doubt  or  uncertainty. 

6.  Identify  the  relevant  stakeholders  associated  with  each  risk. 


SP  2.2  Evaluate,  Categorize,  and  Prioritize  Risks 

Evaluate  and  categorize  each  identified  risk  using  the  defined 
risk  categories  and  parameters,  and  determine  its  relative 
priority. 


The  evaluation  of  risks  is  needed  to  assign  relative  importance  to  each 
identified  risk,  and  is  used  in  determining  when  appropriate 
management  attention  is  required.  Often  it  is  useful  to  aggregate  risks 
based  on  their  interrelationships,  and  develop  options  at  an  aggregate 
level.  When  an  aggregate  risk  is  formed  by  a  roll  up  of  lower  level  risks, 
care  must  be  taken  to  ensure  that  important  lower  level  risks  are  not 
ignored. 

Collectively,  the  activities  of  risk  evaluation,  categorization,  and 
prioritization  are  sometimes  called  “risk  assessment”  or  “risk  analysis.” 

Typical  Work  Products 

1 .  List  of  risks,  with  a  priority  assigned  to  each  risk 
Subpractices 

1.  Evaluate  the  identified  risks  using  the  defined  risk  parameters. 

Each  risk  is  evaluated  and  assigned  values  in  accordance  with  the  defined  risk 
parameters,  which  may  include  likelihood,  consequence  (severity,  or  impact),  and 
thresholds.  The  assigned  risk  parameter  values  can  be  integrated  to  produce 
additional  measures,  such  as  risk  exposure,  which  can  be  used  to  prioritize  risks 
for  handling. 

Often,  a  scale  with  three  to  five  values  is  used  to  evaluate  both  likelihood  and 
consequence.  Likelihood,  for  example,  can  be  categorized  as  remote,  unlikely, 
likely,  highly  likely,  or  a  near  certainty. 
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SG  3 


Examples  for  consequences  include  the  following: 

:  •  Low 
i  •  Medium 
|  •  High 
:  •  Negligible 
:  •  Marginal 
|  •  Significant 
|  •  Critical 
•  Catastrophic 

Probability  values  are  frequently  used  to  quantify  likelihood.  Consequences  are 
generally  related  to  cost,  schedule,  environmental  impact,  or  human  measures 
(e.g.,  labor  hours  lost  and  severity  of  injury). 

This  evaluation  is  often  a  difficult  and  time-consuming  task.  Specific  expertise  or 
group  techniques  may  be  needed  to  assess  the  risks  and  gain  confidence  in  the 
prioritization.  In  addition,  priorities  may  require  reevaluation  as  time  progresses. 

2.  Categorize  and  group  risks  according  to  the  defined  risk 
categories. 

Risks  are  categorized  into  the  defined  risk  categories,  providing  a  means  to  look 
at  risks  according  to  their  source,  taxonomy,  or  project  component.  Related  or 
equivalent  risks  may  be  grouped  for  efficient  handling.  The  cause-and-effect 
relationships  between  related  risks  are  documented. 

3.  Prioritize  risks  for  mitigation. 

A  relative  priority  is  determined  for  each  risk  based  on  the  assigned  risk 
parameters.  Clear  criteria  should  be  used  to  determine  the  risk  priority.  The  intent 
of  prioritization  is  to  determine  the  most  effective  areas  to  which  resources  for 
mitigation  of  risks  can  be  applied  with  the  greatest  positive  impact  to  the  project. 

Mitigate  Risks 

Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse 
impacts  on  achieving  objectives. 

The  steps  in  handling  risks  include  developing  risk-handling  options, 
monitoring  risks,  and  performing  risk-handling  activities  when  defined 
thresholds  are  exceeded.  Risk  mitigation  plans  are  developed  and 
implemented  for  selected  risks  to  proactively  reduce  the  potential 
impact  of  risk  occurrence.  This  can  also  include  contingency  plans  to 
deal  with  the  impact  of  selected  risks  that  may  occur  despite  attempts  to 
mitigate  them.  The  risk  parameters  used  to  trigger  risk-handling 
activities  are  defined  by  the  risk  management  strategy. 
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SP  3.1  Develop  Risk  Mitigation  Plans 

Develop  a  risk  mitigation  plan  for  the  most  important  risks  to 
the  project  as  defined  by  the  risk  management  strategy. 


A  critical  component  of  a  risk  mitigation  plan  is  to  develop  alternative 
courses  of  action,  workarounds,  and  fallback  positions,  with  a 
recommended  course  of  action  for  each  critical  risk.  The  risk  mitigation 
plan  for  a  given  risk  includes  techniques  and  methods  used  to  avoid, 
reduce,  and  control  the  probability  of  occurrence  of  the  risk,  the  extent 
of  damage  incurred  should  the  risk  occur  (sometimes  called  a 
“contingency  plan”),  or  both.  Risks  are  monitored  and  when  they 
exceed  the  established  thresholds,  the  risk  mitigation  plans  are 
deployed  to  return  the  impacted  effort  to  an  acceptable  risk  level.  If  the 
risk  cannot  be  mitigated,  a  contingency  plan  can  be  invoked.  Both  risk 
mitigation  and  contingency  plans  are  often  generated  only  for  selected 
risks  where  the  consequences  of  the  risks  are  determined  to  be  high  or 
unacceptable;  other  risks  may  be  accepted  and  simply  monitored. 

Options  for  handling  risks  typically  include  alternatives  such  as  the 
following: 

•  Risk  avoidance:  Changing  or  lowering  requirements  while  still 
meeting  the  user’s  needs 

•  Risk  control:  Taking  active  steps  to  minimize  risks 

•  Risk  transfer:  Reallocating  requirements  to  lower  the  risks 

•  Risk  monitoring:  Watching  and  periodically  reevaluating  the  risk  for 
changes  to  the  assigned  risk  parameters 

•  Risk  acceptance:  Acknowledgment  of  risk  but  not  taking  any  action 

Often,  especially  for  high  risks,  more  than  one  approach  to  handling  a 
risk  should  be  generated. 


For  example,  in  the  case  of  an  event  that  disrupts  continuity  of  operations,  approaches 
to  risk  management  can  include  the  following: 

•  Resource  reserves  to  respond  to  disruptive  events 

•  Lists  of  appropriate  back-up  equipment  to  be  available 

•  Back-up  personnel  for  key  personnel 

•  Plans  and  results  of/for  testing  emergency  response  systems 

•  Posted  procedures  for  emergencies 

•  Disseminated  lists  of  key  contacts  and  information  resources  for  emergencies 


In  many  cases,  risks  will  be  accepted  or  watched.  Risk  acceptance  is 
usually  done  when  the  risk  is  judged  too  low  for  formal  mitigation,  or 
when  there  appears  to  be  no  viable  way  to  reduce  the  risk.  If  a  risk  is 
accepted,  the  rationale  for  this  decision  should  be  documented.  Risks 
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are  watched  when  there  is  an  objectively  defined,  verifiable,  and 
documented  threshold  of  performance,  time,  or  risk  exposure  (the 
combination  of  likelihood  and  consequence)  that  will  trigger  risk 
mitigation  planning  or  invoke  a  contingency  plan  if  it  is  needed. 

Adequate  consideration  should  be  given  early  to  technology 
demonstrations,  models,  simulations,  pilots,  and  prototypes  as  part  of 
risk  mitigation  planning. 

Typical  Work  Products 

1.  Documented  handling  options  for  each  identified  risk 

2.  Risk  mitigation  plans 

3.  Contingency  plans 

4.  List  of  those  responsible  for  tracking  and  addressing  each  risk 
Subpractices 

1 .  Determine  the  levels  and  thresholds  that  define  when  a  risk 
becomes  unacceptable  and  triggers  the  execution  of  a  risk 
mitigation  plan  or  a  contingency  plan. 

Risk  level  (derived  using  a  risk  model)  is  a  measure  combining  the  uncertainty  of 
reaching  an  objective  with  the  consequences  of  failing  to  reach  the  objective. 

Risk  levels  and  thresholds  that  bound  planned  or  acceptable  performance  must 
be  clearly  understood  and  defined  to  provide  a  means  with  which  risk  can  be 
understood.  Proper  categorization  of  risk  is  essential  for  ensuring  appropriate 
priority  based  on  severity  and  the  associated  management  response.  There  may 
be  multiple  thresholds  employed  to  initiate  varying  levels  of  management 
response.  Typically,  thresholds  for  the  execution  of  risk  mitigation  plans  are  set  to 
engage  before  the  execution  of  contingency  plans. 

2.  Identify  the  person  or  group  responsible  for  addressing  each  risk. 

3.  Determine  the  cost-to-benefit  ratio  of  implementing  the  risk 
mitigation  plan  for  each  risk. 

Risk  mitigation  activities  should  be  examined  for  the  benefits  they  provide  versus 
the  resources  they  will  expend.  Just  like  any  other  design  activity,  alternative 
plans  may  need  to  be  developed  and  the  costs  and  benefits  of  each  alternative 
assessed.  The  most  appropriate  plan  is  then  selected  for  implementation.  At  times 
the  risk  may  be  significant  and  the  benefits  small,  but  the  risk  must  be  mitigated  to 
reduce  the  probability  of  incurring  unacceptable  consequences. 

4.  Develop  an  overall  risk  mitigation  plan  for  the  project  to  orchestrate 
the  implementation  of  the  individual  risk  mitigation  and  contingency 
plans. 
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The  complete  set  of  risk  mitigation  plans  may  not  be  affordable.  A  tradeoff 
analysis  should  be  performed  to  prioritize  the  risk  mitigation  plans  for 
implementation. 

5.  Develop  contingency  plans  for  selected  critical  risks  in  the  event 
their  impacts  are  realized. 

Risk  mitigation  plans  are  developed  and  implemented  as  needed  to  proactively 
reduce  risks  before  they  become  problems.  Despite  best  efforts,  some  risks  may 
be  unavoidable  and  will  become  problems  that  impact  the  project.  Contingency 
plans  can  be  developed  for  critical  risks  to  describe  the  actions  a  project  may  take 
to  deal  with  the  occurrence  of  this  impact.  The  intent  is  to  define  a  proactive  plan 
for  handling  the  risk,  either  to  reduce  the  risk  (mitigation)  or  respond  to  the  risk 
(contingency),  but  in  either  event  to  manage  the  risk. 

Some  risk  management  literature  may  consider  contingency  plans  a  synonym  or 
subset  of  risk  mitigation  plans.  These  plans  also  may  be  addressed  together  as 
risk-handling  or  risk  action  plans. 


SP  3.2  Implement  Risk  Mitigation  Plans 

Monitor  the  status  of  each  risk  periodically  and  implement  the 
risk  mitigation  plan  as  appropriate. 


To  effectively  control  and  manage  risks  during  the  work  effort,  follow  a 
proactive  program  to  regularly  monitor  risks  and  the  status  and  results 
of  risk-handling  actions.  The  risk  management  strategy  defines  the 
intervals  at  which  the  risk  status  should  be  revisited.  This  activity  may 
result  in  the  discovery  of  new  risks  or  new  risk-handling  options  that  can 
require  replanning  and  reassessment.  In  either  event,  the  acceptability 
thresholds  associated  with  the  risk  should  be  compared  against  the 
status  to  determine  the  need  for  implementing  a  risk  mitigation  plan. 

Typical  Work  Products 

1 .  Updated  lists  of  risk  status 

2.  Updated  assessments  of  risk  likelihood,  consequence,  and 
thresholds 

3.  Updated  lists  of  risk-handling  options 

4.  Updated  list  of  actions  taken  to  handle  risks 

5.  Risk  mitigation  plans 

Subpractices 
1.  Monitor  risk  status. 

After  a  risk  mitigation  plan  is  initiated,  the  risk  is  still  monitored.  Thresholds  are 
assessed  to  check  for  the  potential  execution  of  a  contingency  plan. 
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A  periodic  mechanism  for  monitoring  should  be  employed. 

2.  Provide  a  method  for  tracking  open  risk-handling  action  items  to 
closure. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  action  items. 

3.  Invoke  selected  risk-handling  options  when  monitored  risks  exceed 
the  defined  thresholds. 

Quite  often,  risk  handling  is  only  performed  for  those  risks  judged  to  be  “high"  and 
“medium.”  The  risk-handling  strategy  for  a  given  risk  may  include  techniques  and 
methods  to  avoid,  reduce,  and  control  the  likelihood  of  the  risk  or  the  extent  of 
damage  incurred  should  the  risk  (anticipated  event  or  situation)  occur  or  both.  In 
this  context,  risk  handling  includes  both  risk  mitigation  plans  and  contingency 
plans. 

Risk-handling  techniques  are  developed  to  avoid,  reduce,  and  control  adverse 
impact  to  project  objectives  and  to  bring  about  acceptable  outcomes  in  light  of 
probable  impacts.  Actions  generated  to  handle  a  risk  require  proper  resource 
loading  and  scheduling  within  plans  and  baseline  schedules.  This  replanning 
effort  needs  to  closely  consider  the  effects  on  adjacent  or  dependent  work 
initiatives  or  activities. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  revising  the  project  plan. 

4.  Establish  a  schedule  or  period  of  performance  for  each  risk¬ 
handling  activity  that  includes  the  start  date  and  anticipated 
completion  date. 

5.  Provide  continued  commitment  of  resources  for  each  plan  to  allow 
successful  execution  of  the  risk-handling  activities. 

6.  Collect  performance  measures  on  the  risk-handling  activities. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 
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Continuous  Only 

GP  1.1 

Perform  Specific  Practices 

Perform  the  specific  practices  of  the  risk  management  process 
to  develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  risk  management  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  defining  a  risk 
management  strategy  and  identifying,  analyzing,  and  mitigating  risks. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  risk 
management  process. 


Elaboration: 

This  plan  for  performing  the  risk  management  process  can  be  included 
in  (or  referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area.  The  plan  called  for  in  this  generic  practice  would 
address  the  comprehensive  planning  for  all  of  the  specific  practices  in 
this  process  area.  In  particular,  this  plan  provides  the  overall  approach 
for  risk  mitigation,  but  is  distinct  from  mitigation  plans  (including 
contingency  plans)  for  specific  risks.  In  contrast,  the  risk  mitigation 
plans  called  for  in  the  specific  practices  would  address  more  focused 
items  such  as  the  levels  that  trigger  risk-handling  activities. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  risk 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 

Elaboration: 

Examples  of  resources  provided  include  the  following  tools: 

I  •  Risk  management  databases 

|  •  Risk  mitigation  tools 

|  •  Prototyping  tools 

i 

•  Modeling  and  simulation 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  risk  management  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  risk  management 
process  as  needed. 


Elaboration: 


Examples  of  training  topics  include  the  following: 

•  Risk  management  concepts  and  activities  (e.g.,  risk  identification,  evaluation, 
monitoring,  and  mitigation) 

•  Measure  selection  for  risk  mitigation 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  risk  management 
process  under  appropriate  levels  of  control. 

Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Risk  management  strategy 

i  •  Identified  risk  items 

:  •  Risk  mitigation  plans 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  risk 
management  process  as  planned. 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following: 

:  •  Establishing  a  collaborative  environment  for  free  and  open  discussion  of  risk 
:  •  Reviewing  the  risk  management  strategy  and  risk  mitigation  plans 
:  •  Participating  in  risk  identification,  analysis,  and  mitigation  activities 
■  •  Communicating  and  reporting  risk  management  status 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  risk  management  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  risks  identified,  managed,  tracked,  and  controlled 

•  Risk  exposure  and  changes  to  the  risk  exposure  for  each  assessed  risk,  and  as  a 
summary  percentage  of  management  reserve 

•  Change  activity  for  the  risk  mitigation  plans  (e.g.,  processes,  schedule,  and 
funding) 

•  Occurrence  of  unanticipated  risks 

•  Risk  categorization  volatility 

•  Comparison  of  estimated  versus  actual  risk  mitigation  effort  and  impact 

•  Schedule  for  risk  analysis  activities 

•  Schedule  of  actions  for  a  specific  mitigation 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  risk  management 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance. 
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Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

I  •  Establishing  and  maintaining  a  risk  management  strategy 
I  •  Identifying  and  analyzing  risks 

:  •  Mitigating  risks 

i  Examples  of  work  products  reviewed  include  the  following: 

;  •  Risk  management  strategy 

•  Risk  mitigation  plans 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  risk 
management  process  with  higher  level  management  and 
resolve  issues. 


Elaboration: 

Reviews  of  the  project  risk  status  are  held  on  a  periodic  and  event- 
driven  basis,  with  appropriate  levels  of  management,  to  provide  visibility 
into  the  potential  for  project  risk  exposure  and  appropriate  corrective 
action. 


Typically,  these  reviews  include  a  summary  of  the  most  critical  risks, 
key  risk  parameters  (such  as  likelihood  and  consequence  of  the  risks), 
and  the  status  of  risk  mitigation  efforts. 


Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  risk 
management  process. 


Risk  Management  (RSKM) 


437 


CMMI  for  Development 
Version  1.2 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  risk  management  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and 
process  assets. 

Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Risk  parameters 

•  Risk  categories 

•  Risk  status  reports 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  risk 
management  process,  which  address  quality  and  process 
performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  risk  management  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  risk  management 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization. 

GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  risk  management  process. 
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SUPPLIER  AGREEMENT  MANAGEMENT 

A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Supplier  Agreement  Management  (SAM)  is  to  manage 
the  acquisition  of  products  from  suppliers. 


Introductory  Notes 


The  Supplier  Agreement  Management  process  area  involves  the 
following: 

•  Determining  the  type  of  acquisition  that  will  be  used  for  the  products 
to  be  acquired 

•  Selecting  suppliers 

•  Establishing  and  maintaining  agreements  with  suppliers 

•  Executing  the  supplier  agreement 

•  Monitoring  selected  supplier  processes 

•  Evaluating  selected  supplier  work  products 

•  Accepting  delivery  of  acquired  products 

•  Transitioning  acquired  products  to  the  project 

This  process  area  primarily  addresses  the  acquisition  of  products  and 
product  components  that  are  delivered  to  the  project’s  customer. 
Throughout  the  process  areas,  where  we  use  the  terms  product  and 
product  component,  their  intended  meanings  also  encompass  services 
and  their  components. 


Examples  of  products  and  product  components  that  may  be  acquired  by  the  project 
include  the  following: 

•  Subsystems  (e.g.,  navigational  system  on  an  airplane) 

•  Software 

•  Hardware 

•  Documentation  (e.g.,  installation,  operator's,  and  user's  manuals) 

•  Parts  and  materials  (e.g.,  gauges,  switches,  wheels,  steel,  and  raw  materials) 


To  minimize  risks  to  the  project,  this  process  area  can  also  address  the 
acquisition  of  significant  products  and  product  components  not 
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delivered  to  the  project’s  customer  but  used  to  develop  and  maintain 
the  product  or  service  (for  example,  development  tools  and  test 
environments). 

Typically,  the  products  to  be  acquired  by  the  project  are  determined 
during  the  early  stages  of  the  planning  and  development  of  the  product. 
The  Technical  Solution  process  area  provides  practices  for  determining 
the  products  and  product  components  that  may  be  acquired  from 
suppliers. 

This  process  area  does  not  directly  address  arrangements  in  which  the 
supplier  is  integrated  into  the  project  team  and  uses  the  same 
processes  and  reports  to  the  same  management  as  the  product 
developers  (for  example,  integrated  teams).  Typically,  these  situations 
are  handled  by  other  processes  or  functions,  possibly  external  to  the 
project,  though  some  of  the  specific  practices  of  this  process  area  may 
be  useful  in  managing  the  formal  agreement  with  such  a  supplier. 

Suppliers  may  take  many  forms  depending  on  business  needs, 
including  in-house  vendors  (i.e.,  vendors  that  are  in  the  same 
organization  but  are  external  to  the  project),  fabrication  capabilities  and 
laboratories,  and  commercial  vendors.  (See  the  definition  of  “supplier” 
in  the  glossary.) 

A  formal  agreement  is  established  to  manage  the  relationship  between 
the  organization  and  the  supplier.  A  formal  agreement  is  any  legal 
agreement  between  the  organization  (representing  the  project)  and  the 
supplier.  This  agreement  may  be  a  contract,  license,  service  level 
agreement,  or  memorandum  of  agreement.  The  acquired  product  is 
delivered  to  the  project  from  the  supplier  according  to  this  formal 
agreement  (also  known  as  the  “supplier  agreement”). 


Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  projects  and  taking  corrective  action. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  defining  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements,  including  the  traceability  of 
requirements  for  products  acquired  from  suppliers. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
determining  the  products  and  product  components  that  may  be 
acquired  from  suppliers. 
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Specific  Goal  and  Practice  Summary 

SG  1  Establish  Supplier  Agreements 

SP1.1  Determine  Acquisition  Type 

SP  1 .2  Select  Suppliers 

SP  1.3  Establish  Supplier  Agreements 

SG  2  Satisfy  Supplier  Agreements 

SP  2.1  Execute  the  Supplier  Agreement 

SP  2.2  Monitor  Selected  Supplier  Processes 

SP  2.3  Evaluate  Selected  Supplier  Work  Products 
SP  2.4  Accept  the  Acquired  Product 

SP  2.5  Transition  Products 


Specific  Practices  by  Goal 


SGI  Establish  Supplier  Agreements 

Agreements  with  the  suppliers  are  established  and  maintained. 

SP  1.1  Determine  Acquisition  Type 

Determine  the  type  of  acquisition  for  each  product  or  product 
component  to  be  acquired. 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
identifying  the  products  and  product  components  to  be  acquired. 

There  are  many  different  types  of  acquisition  that  can  be  used  to 
acquire  products  and  product  components  that  will  be  used  by  the 
project. 


Examples  of  types  of  acquisition  include  the  following: 

•  Purchasing  commercial  off-the-shelf  (COTS)  products 

•  Obtaining  products  through  a  contractual  agreement 

•  Obtaining  products  from  an  in-house  vendor 

•  Obtaining  products  from  the  customer 

•  Combining  some  of  the  above  (e.g.,  contracting  for  a  modification  to  a  COTS 
product  or  having  another  part  of  the  business  enterprise  codevelop  products  with 
an  external  supplier) 


In  the  event  that  COTS  products  are  desired,  care  in  evaluating  and 
selecting  these  products  and  the  vendor  may  be  critical  to  the  project. 
Things  to  consider  in  the  selection  decision  include  proprietary  issues 
and  the  availability  of  the  products. 

Typical  Work  Products 

1 .  List  of  the  acquisition  types  that  will  be  used  for  all  products  and 
product  components  to  be  acquired 
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SP1.2  Select  Suppliers 

Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet 
the  specified  requirements  and  established  criteria. 


Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation  approaches  that  can  be  used  to 
select  suppliers. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  specified  requirements. 

Criteria  should  be  established  to  address  factors  that  are  important  to 
the  project. 


Examples  of  factors  include  the  following: 

•  Geographical  location  of  the  supplier 

•  Supplier’s  performance  records  on  similar  work 

•  Engineering  capabilities 

•  Staff  and  facilities  available  to  perform  the  work 

•  Prior  experience  in  similar  applications 


Typical  Work  Products 

1.  Market  studies 

2.  List  of  candidate  suppliers 

3.  Preferred  supplier  list 

4.  Trade  study  or  other  record  of  evaluation  criteria,  advantages  and 
disadvantages  of  candidate  suppliers,  and  rationale  for  selection  of 
suppliers 

5.  Solicitation  materials  and  requirements 
Subpractices 

1 .  Establish  and  document  criteria  for  evaluating  potential  suppliers. 

2.  Identify  potential  suppliers  and  distribute  solicitation  material  and 
requirements  to  them. 

A  proactive  manner  of  performing  this  activity  is  to  conduct  market  research  to 
identify  potential  sources  of  candidate  products  to  be  acquired,  including 
candidates  from  suppliers  of  custom-made  products  and  vendors  of  COTS 
products. 

Refer  to  the  Organizational  Innovation  and  Deployment  process 
area  for  examples  of  sources  of  process  and  technology 
improvements  and  how  to  pilot  and  evaluate  such  improvements. 
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3.  Evaluate  proposals  according  to  evaluation  criteria. 

4.  Evaluate  risks  associated  with  each  proposed  supplier. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  evaluating  project  risks. 

5.  Evaluate  proposed  suppliers'  ability  to  perform  the  work. 

Examples  of  methods  to  evaluate  the  proposed  supplier’s  ability  to  perform  the 
:  work  include  the  following: 

i  •  Evaluation  of  prior  experience  in  similar  applications 

:  •  Evaluation  of  prior  performance  on  similar  work 

i  •  Evaluation  of  management  capabilities 

|  •  Capability  evaluations 

i  •  Evaluation  of  staff  available  to  perform  the  work 

i  •  Evaluation  of  available  facilities  and  resources 

|  •  Evaluation  of  the  project’s  ability  to  work  with  the  proposed  supplier 

j  •  Evaluation  of  the  impact  of  candidate  COTS  products  on  the  project's  plan  and 
commitments 

When  COTS  products  are  being  evaluated  consider  the  following: 
i  •  Cost  of  the  COTS  products 

j  •  Cost  and  effort  to  incorporate  the  COTS  products  into  the  project 
j  •  Security  requirements 

•  Benefits  and  impacts  that  may  result  from  future  product  releases 

Future  releases  of  the  COTS  product  may  provide  additional  features  that  support 
planned  or  anticipated  enhancements  for  the  project,  but  may  result  in  the 
supplier  discontinuing  support  of  its  current  release. 

6.  Select  the  supplier. 

SP  1.3  Establish  Supplier  Agreements 

Establish  and  maintain  formal  agreements  with  the  supplier. 


IPPD  Addition 

When  integrated  teams  are  formed,  team  membership  should  be 
negotiated  with  suppliers  and  incorporated  into  the  agreement.  The 
agreement  should  identify  any  integrated  decision  making,  reporting 
requirements  (business  and  technical),  and  trade  studies  requiring  supplier 
involvement.  The  supplier  efforts  should  be  orchestrated  to  support  the 
IPPD  efforts  undertaken  by  the  acquirer. 
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A  formal  agreement  is  any  legal  agreement  between  the  organization 
(representing  the  project)  and  the  supplier.  This  agreement  may  be  a 
contract,  license,  service  level  agreement,  or  memorandum  of 
agreement. 

The  content  of  the  agreement  should  specify  the  reviews,  monitoring, 
evaluations,  and  acceptance  tests  to  be  performed,  if  such  activities  are 
appropriate  to  the  acquisition  or  product  being  acquired. 

Typical  Work  Products 

1 .  Statements  of  work 

2.  Contracts 

3.  Memoranda  of  agreement 

4.  Licensing  agreement 

Subpractices 

1.  Revise  the  requirements  (e.g.,  product  requirements  and  service 
level  requirements)  to  be  fulfilled  by  the  supplier  to  reflect 
negotiations  with  the  supplier  when  necessary. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  revising  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  changes  to  requirements. 

2.  Document  what  the  project  will  provide  to  the  supplier. 

Include  the  following: 

•  Project-furnished  facilities 

•  Documentation 

•  Services 

3.  Document  the  supplier  agreement. 

The  supplier  agreement  should  include  a  statement  of  work,  a  specification,  terms 
and  conditions,  a  list  of  deliverables,  a  schedule,  a  budget,  and  a  defined 
acceptance  process. 

This  subpractice  typically  includes  the  following: 

•  Establishing  the  statement  of  work,  specification,  terms  and  conditions,  list  of 
deliverables,  schedule,  budget,  and  acceptance  process 

•  Identifying  who  from  the  project  and  supplier  are  responsible  and  authorized  to 
make  changes  to  the  supplier  agreement 

•  Identifying  how  requirements  changes  and  changes  to  the  supplier  agreement  are 
to  be  determined,  communicated,  and  addressed 
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•  Identifying  standards  and  procedures  that  will  be  followed 

•  Identifying  critical  dependencies  between  the  project  and  the  supplier 

•  Identifying  the  type  and  depth  of  project  oversight  of  the  supplier,  procedures,  and 
evaluation  criteria  to  be  used  in  monitoring  supplier  performance  including 
selection  of  processes  to  be  monitored  and  work  products  to  be  evaluated 

•  Identifying  the  types  of  reviews  that  will  be  conducted  with  the  supplier 

•  Identifying  the  supplier’s  responsibilities  for  ongoing  maintenance  and  support  of 
the  acquired  products 

•  Identifying  warranty,  ownership,  and  usage  rights  for  the  acquired  products 

•  Identifying  acceptance  criteria 

In  some  cases,  selection  of  COTS  products  may  require  a  supplier  agreement  in 

addition  to  the  agreements  in  the  product's  license. 


Examples  of  what  could  be  covered  in  an  agreement  with  a  COTS  supplier 
include  the  following: 

•  Discounts  for  large  quantity  purchases 

•  Coverage  of  relevant  stakeholders  under  the  licensing  agreement,  including 
project  suppliers,  team  members,  and  the  project's  customer 

•  Plans  for  future  enhancements 

•  On-site  support,  such  as  responses  to  queries  and  problem  reports 

•  Additional  capabilities  that  are  not  in  the  product 

•  Maintenance  support,  including  support  after  the  product  is  withdrawn  from 
general  availability 


4.  Periodically  review  the  supplier  agreement  to  ensure  it  accurately 
reflects  the  project's  relationship  with  the  supplier  and  current  risks 
and  market  conditions. 

5.  Ensure  that  all  parties  to  the  agreement  understand  and  agree  to 
all  requirements  before  implementing  the  agreement  or  any 
changes. 

6.  Revise  the  supplier  agreement  as  necessary  to  reflect  changes  to 
the  supplier's  processes  or  work  products. 

7.  Revise  the  project's  plans  and  commitments,  including  changes  to 
the  project's  processes  or  work  products,  as  necessary  to  reflect 
the  supplier  agreement. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  revising  the  project  plan. 
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SG  2  Satisfy  Supplier  Agreements 

Agreements  with  the  suppliers  are  satisfied  by  both  the  project  and  the 
supplier. 


SP  2.1  Execute  the  Supplier  Agreement 

Perform  activities  with  the  supplier  as  specified  in  the  supplier 
agreement. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  projects  and  taking  corrective  action. 

Typical  Work  Products 

1 .  Supplier  progress  reports  and  performance  measures 

2.  Supplier  review  materials  and  reports 

3.  Action  items  tracked  to  closure 

4.  Documentation  of  product  and  document  deliveries 

Subpractices 

1 .  Monitor  supplier  progress  and  performance  (schedule,  effort,  cost, 
and  technical  performance)  as  defined  in  the  supplier  agreement. 

2.  Conduct  reviews  with  the  supplier  as  specified  in  the  supplier 
agreement. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  conducting  reviews. 

Reviews  cover  both  formal  and  informal  reviews  and  include  the  following  steps: 

•  Preparing  for  the  review 

•  Ensuring  that  relevant  stakeholders  participate 

•  Conducting  the  review 

•  Identifying,  documenting,  and  tracking  all  action  items  to  closure 

•  Preparing  and  distributing  to  the  relevant  stakeholders  a  summary  report  of  the 
review 

3.  Conduct  technical  reviews  with  the  supplier  as  defined  in  the 
supplier  agreement. 

Technical  reviews  typically  include  the  following: 

•  Providing  the  supplier  with  visibility  into  the  needs  and  desires  of  the  project’s 
customers  and  end  users,  as  appropriate 

•  Reviewing  the  supplier’s  technical  activities  and  verifying  that  the  supplier’s 
interpretation  and  implementation  of  the  requirements  are  consistent  with  the 
project’s  interpretation 
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•  Ensuring  that  technical  commitments  are  being  met  and  that  technical  issues  are 
communicated  and  resolved  in  a  timely  manner 

•  Obtaining  technical  information  about  the  supplier’s  products 

•  Providing  appropriate  technical  information  and  support  to  the  supplier 

4.  Conduct  management  reviews  with  the  supplier  as  defined  in  the 
supplier  agreement. 

Management  reviews  typically  include  the  following: 

•  Reviewing  critical  dependencies 

•  Reviewing  project  risks  involving  the  supplier 

•  Reviewing  schedule  and  budget 

Technical  and  management  reviews  may  be  coordinated  and  held  jointly. 

5.  Use  the  results  of  reviews  to  improve  the  supplier’s  performance 
and  to  establish  and  nurture  long-term  relationships  with  preferred 
suppliers. 

6.  Monitor  risks  involving  the  supplier  and  take  corrective  action  as 
necessary. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  risks. 


SP  2.2  Monitor  Selected  Supplier  Processes 

Select,  monitor,  and  analyze  processes  used  by  the  supplier. 


In  situations  where  there  must  be  tight  alignment  between  some  of  the 
processes  implemented  by  the  supplier  and  those  of  the  project, 
monitoring  these  processes  will  help  prevent  interface  problems. 

The  selection  must  consider  the  impact  of  the  supplier's  processes  on 
the  project.  On  larger  projects  with  significant  subcontracts  for 
development  of  critical  components,  monitoring  of  key  processes  is 
expected.  For  most  vendor  agreements  where  a  product  is  not  being 
developed  or  for  smaller,  less  critical  components,  the  selection  process 
may  determine  that  monitoring  is  not  appropriate.  Between  these 
extremes,  the  overall  risk  should  be  considered  in  selecting  processes 
to  be  monitored. 

The  processes  selected  for  monitoring  should  include  engineering, 
project  management  (including  contracting),  and  support  processes 
critical  to  successful  project  performance. 

Monitoring,  if  not  performed  with  adequate  care,  can  at  one  extreme  be 
invasive  and  burdensome,  or  at  the  other  extreme  be  uninformative  and 
ineffective.  There  should  be  sufficient  monitoring  to  detect  issues,  as 
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early  as  possible,  that  may  affect  the  supplier's  ability  to  satisfy  the 
requirements  of  the  supplier  agreement. 

Analyzing  selected  processes  involves  taking  the  data  obtained  from 
monitoring  selected  supplier  processes  and  analyzing  it  to  determine 
whether  there  are  serious  issues. 

Typical  Work  Products 

1 .  List  of  processes  selected  for  monitoring  or  rationale  for  non¬ 
selection 

2.  Activity  reports 

3.  Performance  reports 

4.  Performance  curves 

5.  Discrepancy  reports 

Subpractices 

1 .  Identify  the  supplier  processes  that  are  critical  to  the  success  of  the 
project. 

2.  Monitor  the  selected  supplier's  processes  for  compliance  with 
requirements  of  the  agreement. 

3.  Analyze  the  results  of  monitoring  the  selected  processes  to  detect 
issues  as  early  as  possible  that  may  affect  the  supplier's  ability  to 
satisfy  the  requirements  of  the  agreement. 

Trend  analysis  can  rely  on  internal  and  external  data. 

Refer  to  the  Verification  process  area  for  more  information  about 
recording  the  results  of  verification  and  analyses. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 


SP  2.3  Evaluate  Selected  Supplier  Work  Products 

Select  and  evaluate  work  products  from  the  supplier  of  custom- 
made  products. 


The  scope  of  this  specific  practice  is  limited  to  suppliers  providing  the 
project  with  custom-made  products,  particularly  those  that  present 
some  risk  to  the  program  due  to  complexity  or  criticality.  The  intent  of 
this  specific  practice  is  to  evaluate  selected  work  products  produced  by 
the  supplier  to  help  detect  issues  as  early  as  possible  that  may  affect 
the  supplier's  ability  to  satisfy  the  requirements  of  the  agreement.  The 
work  products  selected  for  evaluation  should  include  critical  products, 
product  components,  and  work  products  that  provide  insight  into  quality 
issues  as  early  as  possible. 


448 


Supplier  Agreement  Management  (SAM) 


CMMI  for  Development 
Version  1.2 

Typical  Work  Products 

1 .  List  of  work  products  selected  for  monitoring  or  rationale  for  non¬ 
selection 

2.  Activity  reports 

3.  Discrepancy  reports 

Subpractices 

1 .  Identify  those  work  products  that  are  critical  to  the  success  of  the 
project  and  that  should  be  evaluated  to  help  detect  issues  early. 

:  Examples  of  work  products  that  may  be  critical  to  the  success  of  the  project 
:  include  the  following: 

j  •  Requirements 
I  •  Analyses 
:  •  Architecture 

•  Documentation 

2.  Evaluate  the  selected  work  products. 

Work  products  are  evaluated  to  ensure  the  following: 

•  Derived  requirements  are  traceable  to  higher  level  requirements 

•  The  architecture  is  feasible  and  will  satisfy  future  product  growth  and  reuse  needs. 

•  Documentation  that  will  be  used  to  operate  and  to  support  the  product  is 
adequate. 

•  Work  products  are  consistent  with  one  another. 

•  Products  and  product  components  (e.g.,  custom-made,  off-the-shelf,  and 
customer-supplied  products)  can  be  integrated. 

3.  Determine  and  document  actions  needed  to  address  deficiencies 
identified  in  the  evaluations. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

SP  2.4  Accept  the  Acquired  Product 

Ensure  that  the  supplier  agreement  is  satisfied  before 
accepting  the  acquired  product. 


Acceptance  reviews  and  tests  and  configuration  audits  should  be 
completed  before  accepting  the  product  as  defined  in  the  supplier 
agreement. 

Typical  Work  Products 

1 .  Acceptance  test  procedures 
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2.  Acceptance  test  results 

3.  Discrepancy  reports  or  corrective  action  plans 

Subpractices 

1 .  Define  the  acceptance  procedures. 

2.  Review  and  obtain  agreement  with  relevant  stakeholders  on  the 
acceptance  procedures  before  the  acceptance  review  or  test. 

3.  Verify  that  the  acquired  products  satisfy  their  requirements. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  products. 

4.  Confirm  that  the  nontechnical  commitments  associated  with  the 
acquired  work  product  are  satisfied. 

This  may  include  confirming  that  the  appropriate  license,  warranty,  ownership, 
usage,  and  support  or  maintenance  agreements  are  in  place  and  that  all 
supporting  materials  are  received. 

5.  Document  the  results  of  the  acceptance  review  or  test. 

6.  Establish  and  obtain  supplier  agreement  on  an  action  plan  for  any 
acquired  work  products  that  do  not  pass  their  acceptance  review  or 
test. 

7.  Identify,  document,  and  track  action  items  to  closure. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  action  items. 

SP  2.5  Transition  Products 

Transition  the  acquired  products  from  the  supplier  to  the 
project. 


Before  the  acquired  product  is  transferred  to  the  project  for  integration, 
appropriate  planning  and  evaluation  should  occur  to  ensure  a  smooth 
transition. 

Refer  to  the  Product  Integration  process  area  for  more  information 
about  integrating  the  acquired  products. 

Typical  Work  Products 

1.  Transition  plans 

2.  Training  reports 

3.  Support  and  maintenance  reports 
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Subpractices 

1 .  Ensure  that  there  are  appropriate  facilities  to  receive,  store,  use, 
and  maintain  the  acquired  products. 

2.  Ensure  that  appropriate  training  is  provided  for  those  involved  in 
receiving,  storing,  using,  and  maintaining  the  acquired  products. 

3.  Ensure  that  storing,  distributing,  and  using  the  acquired  products 
are  performed  according  to  the  terms  and  conditions  specified  in 
the  supplier  agreement  or  license. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  supplier  agreement 
management  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  supplier  agreement  management  process. 

Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing, 
maintaining,  and  satisfying  supplier  agreements. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  supplier 
agreement  management  process. 


Elaboration: 

Portions  of  this  plan  for  performing  the  supplier  agreement 
management  process  can  be  part  of  (or  referenced  by)  the  project  plan 
as  described  in  the  Project  Planning  process  area.  Often,  however, 


Supplier  Agreement  Management  (SAM) 


451 


CMMI  for  Development 
Version  1.2 


some  portions  of  the  plan  reside  outside  of  the  project  with  an 
independent  group,  such  as  contract  management. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  supplier 
agreement  management  process,  developing  the  work 
products,  and  providing  the  services  of  the  process. 

Elaboration: 

;  Examples  of  resources  provided  include  the  following  tools: 

i  •  Preferred  supplier  lists 

i  •  Requirements  tracking  programs 

•  Project  management  and  scheduling  programs 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  supplier  agreement  management  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  supplier 
agreement  management  process  as  needed. 

Elaboration: 

Examples  of  training  topics  include  the  following: 

|  •  Regulations  and  business  practices  related  to  negotiating  and  working  with 
:  suppliers 

i  •  Acquisition  planning  and  preparation 
i  •  COTS  products  acquisition 

i  •  Supplier  evaluation  and  selection 

i  •  Negotiation  and  conflict  resolution 

i  •  Supplier  management 

;  •  Testing  and  transitioning  of  acquired  products 
•  Receiving,  storing,  using,  and  maintaining  acquired  products 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  supplier  agreement 
management  process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Statements  of  work 

I  •  Supplier  agreements 

|  •  Memoranda  of  agreement 

j  •  Subcontracts 

•  Preferred  supplier  lists 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  supplier 
agreement  management  process  as  planned. 

Elaboration: 

;  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Establishing  criteria  for  evaluation  of  potential  suppliers 

i  •  Reviewing  potential  suppliers 

i  •  Establishing  supplier  agreements 

;  •  Resolving  issues  with  suppliers 

•  Reviewing  supplier  performance 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  supplier  agreement  management 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  changes  made  to  the  requirements  for  the  supplier 

•  Cost  and  schedule  variance  per  supplier  agreement 

•  Number  of  supplier  work  product  evaluations  completed  (planned  versus  actuals) 

•  Number  of  supplier  process  evaluations  completed  (planned  versus  actuals) 

•  Schedule  for  selecting  a  supplier  and  establishing  an  agreement 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  supplier  agreement 
management  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

|  •  Establishing  and  maintaining  supplier  agreements 
:  •  Satisfying  supplier  agreements 

:  Examples  of  work  products  reviewed  include  the  following: 

;  •  Plan  for  Supplier  Agreement  Management 
•  Supplier  agreements 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  supplier 
agreement  management  process  with  higher  level  management 
and  resolve  issues. 


Staged  Only 

GG3  and  its  practices  do  not  apply  for  a  maturity  level  2  rating, 
but  do  apply  for  a  maturity  level  3  rating  and  above. 


Continuous/Maturity  Levels  3-5  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  supplier 
agreement  management  process. 

GP  3.2 

Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  supplier  agreement  management  process  to 
support  the  future  use  and  improvement  of  the  organization’s 
processes  and  process  assets. 

454 


Supplier  Agreement  Management  (SAM) 


CMMI  for  Development 
Version  1.2 


Continuous/Maturity  Levels  3  -  5  Only 

Elaboration: 

:  Examples  of  work  products,  measures,  measurement  results,  and  improvement 
j  information  include  the  following: 

:  •  Results  of  supplier  reviews 
:  •  T rade  studies  used  to  select  suppliers 
:  •  Revision  history  of  supplier  agreements 
i  •  Supplier  performance  reports 
•  Results  of  supplier  work  product  and  process  evaluations 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  supplier 
agreement  management  process,  which  address  quality  and 
process  performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  supplier  agreement  management 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives. 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  supplier  agreement 
management  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  supplier  agreement  management  process. 
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TECHNICAL  SOLUTION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Technical  Solution  (TS)  is  to  design,  develop,  and 
implement  solutions  to  requirements.  Solutions,  designs,  and 
implementations  encompass  products,  product  components,  and 
product-related  lifecycle  processes  either  singly  or  in  combination  as 
appropriate. 


Introductory  Notes 


The  Technical  Solution  process  area  is  applicable  at  any  level  of  the 
product  architecture  and  to  every  product,  product  component,  and 
product-related  lifecycle  process.  Throughout  the  process  areas,  where 
we  use  the  terms  product  and  product  component,  their  intended 
meanings  also  encompass  services  and  their  components. 

The  process  area  focuses  on  the  following: 

•  Evaluating  and  selecting  solutions  (sometimes  referred  to  as 
“design  approaches,”  “design  concepts,”  or  “preliminary  designs”) 
that  potentially  satisfy  an  appropriate  set  of  allocated  requirements 

•  Developing  detailed  designs  for  the  selected  solutions  (detailed  in 
the  context  of  containing  all  the  information  needed  to  manufacture, 
code,  or  otherwise  implement  the  design  as  a  product  or  product 
component) 

•  Implementing  the  designs  as  a  product  or  product  component 

Typically,  these  activities  interactively  support  each  other.  Some  level  of 
design,  at  times  fairly  detailed,  may  be  needed  to  select  solutions. 
Prototypes  or  pilots  may  be  used  as  a  means  of  gaining  sufficient 
knowledge  to  develop  a  technical  data  package  or  a  complete  set  of 
requirements. 

Technical  Solution  specific  practices  apply  not  only  to  the  product  and 
product  components  but  also  to  product-related  lifecycle  processes. 

The  product-related  lifecycle  processes  are  developed  in  concert  with 
the  product  or  product  component.  Such  development  may  include 
selecting  and  adapting  existing  processes  (including  standard 
processes)  for  use  as  well  as  developing  new  processes. 

Processes  associated  with  the  Technical  Solution  process  area  receive 
the  product  and  product  component  requirements  from  the 
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requirements  management  processes.  The  requirements  management 
processes  place  the  requirements,  which  originate  in  requirements 
development  processes,  under  appropriate  configuration  management 
and  maintain  their  traceability  to  previous  requirements. 

For  a  maintenance  or  sustainment  project,  the  requirements  in  need  of 
maintenance  actions  or  redesign  may  be  driven  by  user  needs  or  latent 
defects  in  the  product  components.  New  requirements  may  arise  from 
changes  in  the  operating  environment.  Such  requirements  can  be 
uncovered  during  verification  of  the  product(s)  where  actual 
performance  can  be  compared  against  the  specified  performance  and 
unacceptable  degradation  can  be  identified.  Processes  associated  with 
the  Technical  Solution  process  area  should  be  used  to  perform  the 
maintenance  or  sustainment  design  efforts. 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  requirements  allocations,  establishing  an  operational 
concept,  and  interface  requirements  definition. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews  and  verifying  that  the  product  and  product 
components  meet  requirements. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements.  The  specific  practices  in  the 
Requirements  Management  process  area  are  performed  interactively 
with  those  in  the  Technical  Solution  process  area. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  improving  the  organization’s  technology. 

Specific  Goal  and  Practice  Summary 

SG  1  Select  Product  Component  Solutions 

SP  1 .1  Develop  Alternative  Solutions  and  Selection  Criteria 
SP  1 .2  Select  Product  Component  Solutions 
SG  2  Develop  the  Design 

SP  2.1  Design  the  Product  or  Product  Component 
SP  2.2  Establish  a  Technical  Data  Package 
SP  2.3  Design  Interfaces  Using  Criteria 
SP  2.4  Perform  Make,  Buy,  or  Reuse  Analyses 

SG  3  Implement  the  Product  Design 
SP3.1  Implement  the  Design 
SP  3.2  Develop  Product  Support  Documentation 
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Specific  Practices  by  Goal 


SG  1  Select  Product  Component  Solutions 

Product  or  product  component  solutions  are  selected  from  alternative 
solutions. 

Alternative  solutions  and  their  relative  merits  are  considered  in  advance 
of  selecting  a  solution.  Key  requirements,  design  issues,  and 
constraints  are  established  for  use  in  alternative  solution  analysis. 
Architectural  features  that  provide  a  foundation  for  product  improvement 
and  evolution  are  considered.  Use  of  commercial  off-the-shelf  (COTS) 
product  components  are  considered  relative  to  cost,  schedule, 
performance,  and  risk.  COTS  alternatives  may  be  used  with  or  without 
modification.  Sometimes  such  items  may  require  modifications  to 
aspects  such  as  interfaces  or  a  customization  of  some  of  the  features  to 
better  achieve  product  requirements. 

One  indicator  of  a  good  design  process  is  that  the  design  was  chosen 
after  comparing  and  evaluating  it  against  alternative  solutions. 

Decisions  on  architecture,  custom  development  versus  off  the  shelf, 
and  product  component  modularization  are  typical  of  the  design  choices 
that  are  addressed.  Some  of  these  decisions  may  require  the  use  of  a 
formal  evaluation  process. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  the  use  of  a  formal  evaluation  process. 

Sometimes  the  search  for  solutions  examines  alternative  instances  of 
the  same  requirements  with  no  allocations  needed  for  lower  level 
product  components.  Such  is  the  case  at  the  bottom  of  the  product 
architecture.  There  are  also  cases  where  one  or  more  of  the  solutions 
are  fixed  (e.g.,  a  specific  solution  is  directed  or  available  product 
components,  such  as  COTS,  are  investigated  for  use). 

In  the  general  case,  solutions  are  defined  as  a  set.  That  is,  when 
defining  the  next  layer  of  product  components,  the  solution  for  each  of 
the  product  components  in  the  set  is  established.  The  alternative 
solutions  are  not  only  different  ways  of  addressing  the  same 
requirements,  but  they  also  reflect  a  different  allocation  of  requirements 
among  the  product  components  comprising  the  solution  set.  The 
objective  is  to  optimize  the  set  as  a  whole  and  not  the  individual  pieces. 
There  will  be  significant  interaction  with  processes  associated  with  the 
Requirements  Development  process  area  to  support  the  provisional 
allocations  to  product  components  until  a  solution  set  is  selected  and 
final  allocations  are  established. 

Product-related  lifecycle  processes  are  among  the  product  component 
solutions  that  are  selected  from  alternative  solutions.  Examples  of  these 
product-related  lifecycle  processes  are  the  manufacturing,  delivery,  and 
support  processes. 
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SP  1.1  Develop  Alternative  Solutions  and  Selection  Criteria 


Develop  alternative  solutions  and  selection  criteria. 


Refer  to  the  Allocate  Product  Component  Requirements  specific 
practice  in  the  Requirements  Development  process  area  for  more 
information  about  obtaining  allocations  of  requirements  to  solution 
alternatives  for  the  product  components. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  establishing  criteria  used  in  making  decisions. 


IPPD  Addition 

The  activity  of  selecting  alternative  solutions  and  issues  to  be  subject  to 
decision  analyses  and  trade  studies  is  accomplished  by  the  involvement  of 
relevant  stakeholders.  These  stakeholders  represent  both  business  and 
technical  functions  and  the  concurrent  development  of  the  product  and  the 
product-related  lifecycle  processes  (e.g.,  manufacturing,  support,  training, 
verification,  and  disposal).  In  this  way,  important  issues  surface  earlier  in 
product  development  than  with  traditional  serial  development  and  can  be 
addressed  before  they  become  costly  mistakes. 


Alternative  solutions  need  to  be  identified  and  analyzed  to  enable  the 
selection  of  a  balanced  solution  across  the  life  of  the  product  in  terms  of 
cost,  schedule,  and  performance.  These  solutions  are  based  on 
proposed  product  architectures  that  address  critical  product  qualities 
and  span  a  design  space  of  feasible  solutions.  Specific  practices 
associated  with  the  Develop  the  Design  specific  goal  provide  more 
information  on  developing  potential  product  architectures  that  can  be 
incorporated  into  alternative  solutions  for  the  product. 

Alternative  solutions  frequently  encompass  alternative  requirement 
allocations  to  different  product  components.  These  alternative  solutions 
can  also  include  the  use  of  COTS  solutions  in  the  product  architecture. 
Processes  associated  with  the  Requirements  Development  process 
area  would  then  be  employed  to  provide  a  more  complete  and  robust 
provisional  allocation  of  requirements  to  the  alternative  solutions. 

Alternative  solutions  span  the  acceptable  range  of  cost,  schedule,  and 
performance.  The  product  component  requirements  are  received  and 
used  along  with  design  issues,  constraints,  and  criteria  to  develop  the 
alternative  solutions.  Selection  criteria  would  typically  address  costs 
(e.g.,  time,  people,  and  money),  benefits  (e.g.,  performance,  capability, 
and  effectiveness),  and  risks  (e.g.,  technical,  cost,  and  schedule). 
Considerations  for  alternative  solutions  and  selection  criteria  include  the 
following: 

•  Cost  of  development,  manufacturing,  procurement,  maintenance, 
and  support,  etc. 

•  Performance 
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•  Complexity  of  the  product  component  and  product-related  lifecycle 
processes 

•  Robustness  to  product  operating  and  use  conditions,  operating 
modes,  environments,  and  variations  in  product-related  lifecycle 
processes 

•  Product  expansion  and  growth 

•  Technology  limitations 

•  Sensitivity  to  construction  methods  and  materials 

•  Risk 

•  Evolution  of  requirements  and  technology 

•  Disposal 

•  Capabilities  and  limitations  of  end  users  and  operators 

•  Characteristics  of  COTS  products 

The  considerations  listed  here  are  a  basic  set;  organizations  should 
develop  screening  criteria  to  narrow  down  the  list  of  alternatives  that  are 
consistent  with  their  business  objectives.  Product  lifecycle  cost,  while 
being  a  desirable  parameter  to  minimize,  may  be  outside  the  control  of 
development  organizations.  A  customer  may  not  be  willing  to  pay  for 
features  that  cost  more  in  the  short  term  but  ultimately  decrease  cost 
over  the  life  of  the  product.  In  such  cases,  customers  should  at  least  be 
advised  of  any  potential  for  reducing  lifecycle  costs.  The  criteria  used  in 
selections  of  final  solutions  should  provide  a  balanced  approach  to 
costs,  benefits,  and  risks. 

Typical  Work  Products 

1 .  Alternative  solution  screening  criteria 

2.  Evaluation  reports  of  new  technologies 

3.  Alternative  solutions 

4.  Selection  criteria  for  final  selection 

5.  Evaluation  reports  of  COTS  products 

Subpractices 

1 .  Identify  screening  criteria  to  select  a  set  of  alternative  solutions  for 
consideration. 

2.  Identify  technologies  currently  in  use  and  new  product  technologies 
for  competitive  advantage. 

Refer  to  the  Organizational  Innovation  and  Deployment  process 
area  for  more  information  about  improving  the  organization’s 
technology. 
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The  project  should  identify  technologies  applied  to  current  products  and 
processes  and  monitor  the  progress  of  currently  used  technologies  throughout  the 
life  of  the  project.  The  project  should  identify,  select,  evaluate,  and  invest  in  new 
technologies  to  achieve  competitive  advantage.  Alternative  solutions  could  include 
newly  developed  technologies,  but  could  also  include  applying  mature 
technologies  in  different  applications  or  to  maintain  current  methods. 

3.  Identify  candidate  COTS  products  that  satisfy  the  requirements. 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  evaluating  suppliers. 

These  requirements  include  the  following: 

•  Functionality,  performance,  quality,  and  reliability 

•  Terms  and  conditions  of  warranties  for  the  products 

•  Risk 

•  Suppliers'  responsibilities  for  ongoing  maintenance  and  support  of  the  products 

4.  Generate  alternative  solutions. 

5.  Obtain  a  complete  requirements  allocation  for  each  alternative. 

6.  Develop  the  criteria  for  selecting  the  best  alternative  solution. 

Criteria  should  be  included  that  address  design  issues  for  the  life  of  the  product, 
such  as  provisions  for  more  easily  inserting  new  technologies  or  the  ability  to 
better  exploit  commercial  products.  Examples  include  criteria  related  to  open 
design  or  open  architecture  concepts  for  the  alternatives  being  evaluated. 

SP  1.2  Select  Product  Component  Solutions 

Select  the  product  component  solutions  that  best  satisfy  the 
criteria  established. 


Refer  to  the  Allocate  Product  Component  Requirements  and  Identify 
Interface  Requirements  specific  practices  of  the  Requirements 
Development  process  area  for  information  on  establishing  the  allocated 
requirements  for  product  components  and  interface  requirements 
among  product  components. 

Selecting  product  components  that  best  satisfy  the  criteria  establishes 
the  requirement  allocations  to  product  components.  Lower  level 
requirements  are  generated  from  the  selected  alternative  and  used  to 
develop  the  product  component  design.  Interface  requirements  among 
product  components  are  described,  primarily  functionally.  Physical 
interface  descriptions  are  included  in  the  documentation  for  interfaces 
to  items  and  activities  external  to  the  product. 

The  description  of  the  solutions  and  the  rationale  for  selection  are 
documented.  The  documentation  evolves  throughout  development  as 
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solutions  and  detailed  designs  are  developed  and  those  designs  are 
implemented.  Maintaining  a  record  of  rationale  is  critical  to  downstream 
decision  making.  Such  records  keep  downstream  stakeholders  from 
redoing  work  and  provide  insights  to  apply  technology  as  it  becomes 
available  in  applicable  circumstances. 

Typical  Work  Products 

1 .  Product  component  selection  decisions  and  rationale 

2.  Documented  relationships  between  requirements  and  product 
components 

3.  Documented  solutions,  evaluations,  and  rationale 
Subpractices 

1 .  Evaluate  each  alternative  solution/set  of  solutions  against  the 
selection  criteria  established  in  the  context  of  the  operating 
concepts  and  scenarios. 

Develop  timeline  scenarios  for  product  operation  and  user  interaction  for  each 
alternative  solution. 

2.  Based  on  the  evaluation  of  alternatives,  assess  the  adequacy  of 
the  selection  criteria  and  update  these  criteria  as  necessary. 

3.  Identify  and  resolve  issues  with  the  alternative  solutions  and 
requirements. 

4.  Select  the  best  set  of  alternative  solutions  that  satisfy  the 
established  selection  criteria. 

5.  Establish  the  requirements  associated  with  the  selected  set  of 
alternatives  as  the  set  of  allocated  requirements  to  those  product 
components. 

6.  Identify  the  product  component  solutions  that  will  be  reused  or 
acquired. 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  acquiring  products  and  product 
components. 

7.  Establish  and  maintain  the  documentation  of  the  solutions, 
evaluations,  and  rationale. 


SG  2  Develop  the  Design 

Product  or  product  component  designs  are  developed. 

Product  or  product  component  designs  must  provide  the  appropriate 
content  not  only  for  implementation,  but  also  for  other  phases  of  the 
product  lifecycle  such  as  modification,  reprocurement,  maintenance, 
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sustainment,  and  installation.  The  design  documentation  provides  a 
reference  to  support  mutual  understanding  of  the  design  by  relevant 
stakeholders  and  supports  future  changes  to  the  design  both  during 
development  and  in  subsequent  phases  of  the  product  lifecycle.  A 
complete  design  description  is  documented  in  a  technical  data  package 
that  includes  a  full  range  of  features  and  parameters  including  form,  fit, 
function,  interface,  manufacturing  process  characteristics,  and  other 
parameters.  Established  organizational  or  project  design  standards 
(e.g.,  checklists,  templates,  and  object  frameworks)  form  the  basis  for 
achieving  a  high  degree  of  definition  and  completeness  in  design 
documentation. 


IPPD  Addition 

The  integrated  teams  develop  the  designs  of  the  appropriate  product- 
related  lifecycle  processes  concurrently  with  the  design  of  the  product. 
These  processes  may  be  selected  without  modification  from  the 
organization’s  set  of  standard  processes,  if  appropriate. 


SP  2.1  Design  the  Product  or  Product  Component 

Develop  a  design  for  the  product  or  product  component. 


Product  design  consists  of  two  broad  phases  that  may  overlap  in 
execution:  preliminary  and  detailed  design.  Preliminary  design 
establishes  product  capabilities  and  the  product  architecture,  including 
product  partitions,  product  component  identifications,  system  states  and 
modes,  major  intercomponent  interfaces,  and  external  product 
interfaces.  Detailed  design  fully  defines  the  structure  and  capabilities  of 
the  product  components. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  developing  architecture  requirements. 

Architecture  definition  is  driven  from  a  set  of  architectural  requirements 
developed  during  the  requirements  development  processes.  These 
requirements  express  the  qualities  and  performance  points  that  are 
critical  to  the  success  of  the  product.  The  architecture  defines  structural 
elements  and  coordination  mechanisms  that  either  directly  satisfy 
requirements  or  support  the  achievement  of  the  requirements  as  the 
details  of  the  product  design  are  established.  Architectures  may  include 
standards  and  design  rules  governing  development  of  product 
components  and  their  interfaces  as  well  as  guidance  to  aid  product 
developers.  Specific  practices  in  the  Select  Product  Component 
Solutions  specific  goal  contain  more  information  about  using  product 
architectures  as  a  basis  for  alternative  solutions. 

Architects  postulate  and  develop  a  model  of  the  product,  making 
judgments  about  allocation  of  requirements  to  product  components 
including  hardware  and  software.  Multiple  architectures,  supporting 
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alternative  solutions,  may  be  developed  and  analyzed  to  determine  the 
advantages  and  disadvantages  in  the  context  of  the  architectural 
requirements. 

Operational  concepts  and  scenarios  are  used  to  generate  use  cases 
and  quality  scenarios  that  are  used  to  refine  the  architecture.  They  are 
also  used  as  a  means  to  evaluate  the  suitability  of  the  architecture  for 
its  intended  purpose  during  architecture  evaluations,  which  are 
conducted  periodically  throughout  product  design. 

Refer  to  the  Establish  Operational  Concepts  and  Scenarios  specific 
practice  of  the  Requirements  Development  process  area  for  information 
about  developing  operational  concepts  and  scenarios  used  in 
architecture  evaluation. 


Examples  of  architecture  definition  tasks  include  the  following: 

•  Establishing  the  structural  relations  of  partitions  and  rules  regarding  interfaces 
between  elements  within  partitions,  and  between  partitions 

•  Identifying  major  internal  interfaces  and  all  external  interfaces 

•  Identifying  product  components  and  interfaces  between  them 

•  Defining  coordination  mechanisms  (e.g.,  for  software  and  hardware) 

•  Establishing  infrastructure  capabilities  and  services 

•  Developing  product  component  templates  or  classes  and  frameworks 

•  Establishing  design  rules  and  authority  for  making  decisions 

•  Defining  a  process/thread  model 

•  Defining  physical  deployment  of  software  to  hardware 

•  Identifying  major  reuse  approaches  and  sources 


During  detailed  design,  the  product  architecture  details  are  finalized, 
product  components  are  completely  defined,  and  interfaces  are  fully 
characterized.  Product  component  designs  may  be  optimized  for  certain 
qualities  or  performance  characteristics.  Designers  may  evaluate  the 
use  of  legacy  or  COTS  products  for  the  product  components.  As  the 
design  matures,  the  requirements  assigned  to  lower  level  product 
components  are  tracked  to  ensure  that  those  requirements  are 
satisfied. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  tracking  requirements  for  product  components. 
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For  Software  Engineering 

Detailed  design  is  focused  on  software  product  component  development. 
The  internal  structure  of  product  components  is  defined,  data  schemas  are 
generated,  algorithms  are  developed,  and  heuristics  are  established  to 
provide  product  component  capabilities  that  satisfy  allocated  reguirements. 

For  /Hardware  Engineering 

Detailed  design  is  focused  on  product  development  of  electronic, 
mechanical,  electro-optical,  and  other  hardware  products  and  their 
components.  Electrical  schematics  and  interconnection  diagrams  are 
developed,  mechanical  and  optical  assembly  models  are  generated,  and 
fabrication  and  assembly  processes  are  developed. 

Typical  Work  Products 

1.  Product  architecture 

2.  Product  component  designs 

Subpractices 

1 .  Establish  and  maintain  criteria  against  which  the  design  can  be 
evaluated. 

Examples  of  attributes,  in  addition  to  expected  performance,  for  which  design 
:  criteria  can  be  established,  include  the  following: 

i  •  Modular 
j  •  Clear 
|  •  Simple 
:  •  Maintainable 
i  •  Verifiable 
|  •  Portable 
|  •  Reliable 
i  •  Accurate 
i  •  Secure 
|  •  Scalable 
•  Usable 

2.  Identify,  develop,  or  acquire  the  design  methods  appropriate  for  the 

product. 

Effective  design  methods  can  embody  a  wide  range  of  activities,  tools,  and 
descriptive  techniques.  Whether  a  given  method  is  effective  or  not  depends  on  the 
situation.  Two  companies  may  have  very  effective  design  methods  for  products  in 
which  they  specialize,  but  these  methods  may  not  be  effective  in  cooperative 
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ventures.  Highly  sophisticated  methods  are  not  necessarily  effective  in  the  hands 
of  designers  who  have  not  been  trained  in  the  use  of  the  methods. 

Whether  a  method  is  effective  also  depends  on  how  much  assistance  it  provides 
the  designer,  and  the  cost  effectiveness  of  that  assistance.  For  example,  a 
multiyear  prototyping  effort  may  not  be  appropriate  for  a  simple  product 
component  but  might  be  the  right  thing  to  do  for  an  unprecedented,  expensive, 
and  complex  product  development.  Rapid  prototyping  techniques,  however,  can 
be  highly  effective  for  many  product  components.  Methods  that  use  tools  to 
ensure  that  a  design  will  encompass  all  the  necessary  attributes  needed  to 
implement  the  product  component  design  can  be  very  effective.  For  example,  a 
design  tool  that  “knows”  the  capabilities  of  the  manufacturing  processes  can  allow 
the  variability  of  the  manufacturing  process  to  be  accounted  for  in  the  design 
tolerances. 


Examples  of  techniques  and  methods  that  facilitate  effective  design  include  the 
i  following: 

i  •  Prototypes 
|  •  Structural  models 
|  •  Object-oriented  design 
i  •  Essential  systems  analysis 
j  •  Entity  relationship  models 
j  •  Design  reuse 
•  Design  patterns 

3.  Ensure  that  the  design  adheres  to  applicable  design  standards  and 
criteria. 


Examples  of  design  standards  include  the  following  (some  or  all  of  these 
standards  may  be  design  criteria,  particularly  in  circumstances  where  the 
standards  have  not  been  established): 

•  Operator  interface  standards 

•  Test  Scenarios 

•  Safety  standards 

•  Design  constraints  (e.g.,  electromagnetic  compatibility,  signal  integrity,  and 
environmental) 

•  Production  constraints 

•  Design  tolerances 

•  Parts  standards  (e.g.,  production  scrap  and  waste) 


4.  Ensure  that  the  design  adheres  to  allocated  requirements. 
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Identified  COTS  product  components  must  be  taken  into  account.  For  example, 
putting  existing  product  components  into  the  product  architecture  might  modify  the 
requirements  and  the  requirements  allocation. 

5.  Document  the  design. 


SP  2.2  Establish  a  Technical  Data  Package 

Establish  and  maintain  a  technical  data  package. 


A  technical  data  package  provides  the  developer  with  a  comprehensive 
description  of  the  product  or  product  component  as  it  is  developed. 

Such  a  package  also  provides  procurement  flexibility  in  a  variety  of 
circumstances  such  as  performance-based  contracting  or  build  to  print. 

The  design  is  recorded  in  a  technical  data  package  that  is  created 
during  preliminary  design  to  document  the  architecture  definition.  This 
technical  data  package  is  maintained  throughout  the  life  of  the  product 
to  record  essential  details  of  the  product  design.  The  technical  data 
package  provides  the  description  of  a  product  or  product  component 
(including  product-related  lifecycle  processes  if  not  handled  as  separate 
product  components)  that  supports  an  acquisition  strategy,  or  the 
implementation,  production,  engineering,  and  logistics  support  phases 
of  the  product  lifecycle.  The  description  includes  the  definition  of  the 
required  design  configuration  and  procedures  to  ensure  adequacy  of 
product  or  product  component  performance.  It  includes  all  applicable 
technical  data  such  as  drawings,  associated  lists,  specifications,  design 
descriptions,  design  databases,  standards,  performance  requirements, 
quality  assurance  provisions,  and  packaging  details.  The  technical  data 
package  includes  a  description  of  the  selected  alternative  solution  that 
was  chosen  for  implementation. 

A  technical  data  package  should  include  the  following  if  such 
information  is  appropriate  for  the  type  of  product  and  product 
component  (for  example,  material  and  manufacturing  requirements  may 
not  be  useful  for  product  components  associated  with  software  services 
or  processes): 

•  Product  architecture  description 

•  Allocated  requirements 

•  Product  component  descriptions 

•  Product-related  lifecycle  process  descriptions,  if  not  described  as 
separate  product  components 

•  Key  product  characteristics 

•  Required  physical  characteristics  and  constraints 

•  Interface  requirements 

•  Materials  requirements  (bills  of  material  and  material 
characteristics) 
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•  Fabrication  and  manufacturing  requirements  (for  both  the  original 
equipment  manufacturer  and  field  support) 

•  The  verification  criteria  used  to  ensure  that  requirements  have  been 
achieved 

•  Conditions  of  use  (environments)  and  operating/usage  scenarios, 
modes  and  states  for  operations,  support,  training,  manufacturing, 
disposal,  and  verifications  throughout  the  life  of  the  product 

•  Rationale  for  decisions  and  characteristics  (requirements, 
requirement  allocations,  and  design  choices) 

Because  design  descriptions  can  involve  a  very  large  amount  of  data 
and  can  be  crucial  to  successful  product  component  development,  it  is 
advisable  to  establish  criteria  for  organizing  the  data  and  for  selecting 
the  data  content.  It  is  particularly  useful  to  use  the  product  architecture 
as  a  means  of  organizing  this  data  and  abstracting  views  that  are  clear 
and  relevant  to  an  issue  or  feature  of  interest.  These  views  include  the 
following: 

•  Customers 

•  Requirements 

•  The  environment 

•  Functional 

•  Logical 

•  Security 

•  Data 

•  States/modes 

•  Construction 

•  Management 

These  views  are  documented  in  the  technical  data  package. 

Typical  Work  Products 

1.  Technical  data  package 

Subpractices 

1 .  Determine  the  number  of  levels  of  design  and  the  appropriate  level 
of  documentation  for  each  design  level. 

Determining  the  number  of  levels  of  product  components  (e.g.,  subsystem, 
hardware  configuration  item,  circuit  board,  computer  software  configuration  item 
[CSCI],  computer  software  product  component,  and  computer  software  unit)  that 
require  documentation  and  requirements  traceability  is  important  to  manage 
documentation  costs  and  to  support  integration  and  verification  plans. 
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2.  Base  detailed  design  descriptions  on  the  allocated  product 
component  requirements,  architecture,  and  higher  level  designs. 

3.  Document  the  design  in  the  technical  data  package. 

4.  Document  the  rationale  for  key  (i.e.,  significant  effect  on  cost, 
schedule,  or  technical  performance)  decisions  made  or  defined. 

5.  Revise  the  technical  data  package  as  necessary. 


SP  2.3  Design  Interfaces  Using  Criteria 

Design  product  component  interfaces  using  established 
criteria. 


Interface  designs  include  the  following: 

•  Origination 

•  Destination 

•  Stimulus  and  data  characteristics  for  software 

•  Electrical,  mechanical,  and  functional  characteristics  for  hardware 

•  Services  lines  of  communication 

The  criteria  for  interfaces  frequently  reflect  critical  parameters  that  must 
be  defined,  or  at  least  investigated,  to  ascertain  their  applicability. 

These  parameters  are  often  peculiar  to  a  given  type  of  product  (e.g., 
software,  mechanical,  electrical,  and  service)  and  are  often  associated 
with  safety,  security,  durability,  and  mission-critical  characteristics. 

Refer  to  the  Identify  Interface  Requirements  specific  practice  in  the 
Requirements  Development  process  area  for  more  information  about 
identifying  product  and  product  component  interface  requirements. 

Typical  Work  Products 

1.  Interface  design  specifications 

2.  Interface  control  documents 

3.  Interface  specification  criteria 

4.  Rationale  for  selected  interface  design 

Subpractices 

1 .  Define  interface  criteria. 

These  criteria  can  be  a  part  of  the  organizational  process  assets. 
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2.  Identify  interfaces  associated  with  other  product  components. 

3.  Identify  interfaces  associated  with  external  items. 

4.  Identify  interfaces  between  product  components  and  the  product- 
related  lifecycle  processes. 

For  example,  such  interfaces  could  include  those  between  a  product  component 
to  be  fabricated  and  the  jigs  and  fixtures  used  to  enable  that  fabrication  during  the 
manufacturing  process. 

5.  Apply  the  criteria  to  the  interface  design  alternatives. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for 
more  information  about  identifying  criteria  and  selecting 
alternatives  based  on  those  criteria. 

6.  Document  the  selected  interface  designs  and  the  rationale  for  the 
selection. 


SP  2.4  Perform  Make,  Buy,  or  Reuse  Analyses 

Evaluate  whether  the  product  components  should  be 
developed,  purchased,  or  reused  based  on  established  criteria. 


The  determination  of  what  products  or  product  components  will  be 
acquired  is  frequently  referred  to  as  a  “make-or-buy  analysis.”  It  is 
based  on  an  analysis  of  the  needs  of  the  project.  This  make-or-buy 
analysis  begins  early  in  the  project  during  the  first  iteration  of  design; 
continues  during  the  design  process;  and  is  completed  with  the  decision 
to  develop,  acquire,  or  reuse  the  product. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  determining  the  product  and  product  component 
requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements. 

Factors  affecting  the  make-or-buy  decision  include  the  following: 

•  Functions  the  products  will  provide  and  how  these  functions  will  fit 
into  the  project 

•  Available  project  resources  and  skills 

•  Costs  of  acquiring  versus  developing  internally 

•  Critical  delivery  and  integration  dates 

•  Strategic  business  alliances,  including  high-level  business 
requirements 

•  Market  research  of  available  products,  including  COTS  products 

•  Functionality  and  quality  of  available  products 
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•  Skills  and  capabilities  of  potential  suppliers 

•  Impact  on  core  competencies 

•  Licenses,  warranties,  responsibilities,  and  limitations  associated 
with  products  being  acquired 

•  Product  availability 

•  Proprietary  issues 

•  Risk  reduction 

The  make-or-buy  decision  can  be  conducted  using  a  formal  evaluation 
approach. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  defining  criteria  and  alternatives  and  performing 
formal  evaluations. 

As  technology  evolves,  so  does  the  rationale  for  choosing  to  develop  or 
purchase  a  product  component.  While  complex  development  efforts 
may  favor  purchasing  an  off-the-shelf  product  component,  advances  in 
productivity  and  tools  may  provide  an  opposing  rationale.  Off-the-shelf 
products  may  have  incomplete  or  inaccurate  documentation  and  may  or 
may  not  be  supported  in  the  future. 

Once  the  decision  is  made  to  purchase  an  off-the-shelf  product 
component,  the  requirements  are  used  to  establish  a  supplier 
agreement.  There  are  times  when  “off  the  shelf”  refers  to  an  existing 
item  that  may  not  be  readily  available  in  the  marketplace.  For  example, 
some  types  of  aircraft  and  engines  are  not  truly  “off  the  shelf”  but  can 
be  readily  procured.  In  some  cases  the  use  of  such  nondeveloped  items 
is  because  the  specifics  of  the  performance  and  other  product 
characteristics  expected  need  to  be  within  the  limits  specified.  In  these 
cases,  the  requirements  and  acceptance  criteria  may  need  to  be 
included  in  the  supplier  agreement  and  managed.  In  other  cases,  the 
off-the-shelf  product  is  literally  off  the  shelf  (word  processing  software, 
for  example)  and  there  is  no  agreement  with  the  supplier  that  needs  to 
be  managed. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  how  to  address  the  acquisition  of  the  product 
components  that  will  be  purchased. 

Typical  Work  Products 

1 .  Criteria  for  design  and  product  component  reuse 

2.  Make-or-buy  analyses 

3.  Guidelines  for  choosing  COTS  product  components 
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SG  3 


Subpractices 

1 .  Develop  criteria  for  the  reuse  of  product  component  designs. 

2.  Analyze  designs  to  determine  if  product  components  should  be 
developed,  reused,  or  purchased. 

3.  Analyze  implications  for  maintenance  when  considering  purchased 
or  nondevelopmental  (e.g.,  COTS,  government  off  the  shelf,  and 
reuse)  items. 


Examples  of  implications  for  maintenance  include  the  following: 

•  Compatibility  with  future  releases  of  COTS  products 

•  Configuration  management  of  vendor  changes 

•  Defects  in  the  nondevelopment  item  and  their  resolution 

•  Unplanned  obsolescence 


Implement  the  Product  Design 

Product  components,  and  associated  support  documentation,  are 
implemented  from  their  designs. 

Product  components  are  implemented  from  the  designs  established  by 
the  specific  practices  in  the  Develop  the  Design  specific  goal.  The 
implementation  usually  includes  unit  testing  of  the  product  components 
before  sending  them  to  product  integration  and  development  of  end- 
user  documentation. 


SP  3.1  Implement  the  Design 

Implement  the  designs  of  the  product  components. 


Once  the  design  has  been  completed,  it  is  implemented  as  a  product 
component.  The  characteristics  of  that  implementation  depend  on  the 
type  of  product  component. 

Design  implementation  at  the  top  level  of  the  product  hierarchy  involves 
the  specification  of  each  of  the  product  components  at  the  next  level  of 
the  product  hierarchy.  This  activity  includes  the  allocation,  refinement, 
and  verification  of  each  product  component.  It  also  involves  the 
coordination  between  the  various  product  component  development 
efforts. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  the  allocation  and  refinement  of  requirements. 

Refer  to  the  Product  Integration  process  area  for  more  information 
about  the  management  of  interfaces  and  the  integration  of  products  and 
product  components. 
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Example  characteristics  of  this  implementation  are  as  follows: 

•  Software  is  coded. 

•  Data  is  documented. 

•  Services  are  documented. 

•  Electrical  and  mechanical  parts  are  fabricated. 

•  Product-unique  manufacturing  processes  are  put  into  operation. 

•  Processes  are  documented. 

•  Facilities  are  constructed. 

•  Materials  are  produced  (e.g.,  a  product-unique  material  could  be  petroleum,  oil,  a 
lubricant,  or  a  new  alloy). 


Typical  Work  Products 
1.  Implemented  design 

Subpractices 

1 .  Use  effective  methods  to  implement  the  product  components. 

For  Software  Engineering 

Examples  of  software  coding  methods  include  the  following: 

|  •  Structured  programming 
i  •  Object-oriented  programming 
:  •  Automatic  code  generation 
i  •  Software  code  reuse 
•  Use  of  applicable  design  patterns 


For  Fiardware  Engineering 

Examples  of  hardware  implementation  methods  include  the  following: 

•  Gate  level  synthesis 

•  Circuit  board  layout  (place  and  route) 

•  Computer  Aided  Design  drawing 

•  Post  layout  simulation 

•  Fabrication  methods 


2.  Adhere  to  applicable  standards  and  criteria. 
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Examples  of  implementation  standards  include  the  following: 

:  •  Language  standards  (e.g.,  standards  for  software  programming  languages  and 
:  hardware  description  languages) 

i  •  Drawing  requirements 

|  •  Standard  parts  lists 

:  •  Manufactured  parts 

i  •  Structure  and  hierarchy  of  software  product  components 
:  •  Process  and  quality  standards 

:  Examples  of  criteria  include  the  following: 

|  •  Modularity 
:  •  Clarity 
|  •  Simplicity 
|  •  Reliability 
:  •  Safety 

•  Maintainability 

3.  Conduct  peer  reviews  of  the  selected  product  components. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews. 

4.  Perform  unit  testing  of  the  product  component  as  appropriate. 

Note  that  unit  testing  is  not  limited  to  software.  Unit  testing  involves  the  testing  of 
individual  hardware  or  software  units  or  groups  of  related  items  prior  to  integration 
of  those  items. 

Refer  to  the  Verification  process  area  for  more  information  about 
verification  methods  and  procedures  and  about  verifying  work 
products  against  their  specified  requirements. 

For  Software  Engineering 
\  Examples  of  unit  testing  methods  include  the  following: 

:  •  Statement  coverage  testing 
:  •  Branch  coverage  testing 
|  •  Predicate  coverage  testing 
:  •  Path  coverage  testing 
i  •  Boundary  value  testing 

•  Special  value  testing 
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For  Hardware  Engineering 

Examples  of  unit  testing  methods  include  the  following: 

•  Functional  testing 

•  Radiation  inspection  testing 

•  Environmental  testing_ 


5.  Revise  the  product  component  as  necessary. 


An  example  of  when  the  product  component  may  need  to  be  revised  is  when 
problems  surface  during  implementation  that  could  not  be  foreseen  during  design. 


SP  3.2  Develop  Product  Support  Documentation 

Develop  and  maintain  the  end-use  documentation. 

This  specific  practice  develops  and  maintains  the  documentation  that 
will  be  used  to  install,  operate,  and  maintain  the  product. 

Typical  Work  Products 

1.  End-user  training  materials 

2.  User's  manual 

3.  Operator's  manual 

4.  Maintenance  manual 

5.  Online  help 

Subpractices 

1 .  Review  the  requirements,  design,  product,  and  test  results  to 
ensure  that  issues  affecting  the  installation,  operation,  and 
maintenance  documentation  are  identified  and  resolved. 

2.  Use  effective  methods  to  develop  the  installation,  operation,  and 
maintenance  documentation. 

3.  Adhere  to  the  applicable  documentation  standards. 


Technical  Solution  (TS) 


475 


CMMI  for  Development 
Version  1.2 


Examples  of  documentation  standards  include  the  following: 

•  Compatibility  with  designated  word  processors 

•  Acceptable  fonts 

•  Numbering  of  pages,  sections,  and  paragraphs 

•  Consistency  with  a  designated  style  manual 

•  Use  of  abbreviations 

•  Security  classification  markings 

•  Internationalization  requirements 


4.  Develop  preliminary  versions  of  the  installation,  operation,  and 
maintenance  documentation  in  early  phases  of  the  project  lifecycle 
for  review  by  the  relevant  stakeholders. 

5.  Conduct  peer  reviews  of  the  installation,  operation,  and 
maintenance  documentation. 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews. 

6.  Revise  the  installation,  operation,  and  maintenance  documentation 
as  necessary. 


Examples  of  when  documentation  may  need  to  be  revised  include  when  the 
following  events  occur: 

•  Requirements  change 

•  Design  changes  are  made 

•  Product  changes  are  made 

•  Documentation  errors  are  identified 

•  Workaround  fixes  are  identified 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 
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Continuous  Only 

GP  1.1 

Perform  Specific  Practices 

Perform  the  specific  practices  of  the  technical  solution  process 
to  develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  technical  solution  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  addressing  the 
iterative  cycle  in  which  product  component  solutions  are  selected, 
product  and  product  component  designs  are  developed,  and  the 
product  component  designs  are  implemented. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  technical 
solution  process. 


Elaboration: 

This  plan  for  performing  the  technical  solution  process  can  be  part  of  (or 
referenced  by)  the  project  plan  as  described  in  the  Project  Planning 
process  area. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  technical 
solution  process,  developing  the  work  products,  and  providing 
the  services  of  the  process. 


Elaboration: 

Special  facilities  may  be  required  for  developing,  designing,  and 
implementing  solutions  to  requirements.  When  necessary,  the  facilities 
required  for  the  activities  in  the  Technical  Solution  process  area  are 
developed  or  purchased. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Design  specification  tools 

•  Simulators  and  modeling  tools 

•  Prototyping  tools 

•  Scenario  definition  and  management  tools 

•  Requirements  tracking  tools 

•  Interactive  documentation  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  technical  solution  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  technical 
solution  process  as  needed. 

Elaboration: 

i  Examples  of  training  topics  include  the  following: 

I  •  Application  domain  of  the  product  and  product  components 
|  •  Design  methods 

|  •  Interface  design 

:  •  Unit  testing  techniques 

•  Standards  (e.g.,  product,  safety,  human  factors,  and  environmental) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  technical  solution 
process  under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Product,  product  component  and  interface  designs 
;•  Technical  data  packages 
|  •  Interface  design  documents 
j  •  Criteria  for  design  and  product  component  reuse 

i  •  Implemented  designs  (e.g.,  software  code  and  fabricated  product  components) 

•  User,  installation,  operation,  and  maintenance  documentation 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  technical 
solution  process  as  planned. 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Developing  alternative  solutions  and  selection  criteria 

•  Obtaining  approval  on  external  interface  specifications  and  design  descriptions 

•  Developing  the  technical  data  package 

•  Assessing  the  make,  buy,  or  reuse  alternatives  for  product  components 

•  Implementing  the  design 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  technical  solution  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action. 
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Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Cost,  schedule,  and  effort  expended  for  rework 

•  Percentage  of  requirements  addressed  in  the  product  or  product  component 
design 

•  Size  and  complexity  of  the  product,  product  components,  interfaces,  and 
documentation 

•  Defect  density  of  technical  solutions  work  products 

•  Schedule  for  design  activities 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  technical  solution 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance. 

Elaboration: 

'  Examples  of  activities  reviewed  include  the  following: 

|  •  Selecting  product  component  solutions 
;  •  Developing  product  and  product  component  designs 
;  •  Implementing  product  component  designs 

Examples  of  work  products  reviewed  include  the  following: 

:•  Technical  data  packages 
i  •  Product,  product  component,  and  interface  designs 
i  •  Implemented  designs  (e.g.,  software  code  and  fabricated  product  components) 
•  User,  installation,  operation,  and  maintenance  documentation 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  technical 
solution  process  with  higher  level  management  and  resolve 
issues. 
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Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  technical 
solution  process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  technical  solution  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and 
process  assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Results  of  the  make,  buy,  or  reuse  analysis 

•  Design  defect  density 

•  Results  of  applying  new  methods  and  tools 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  technical 
solution  process,  which  address  quality  and  process 
performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  technical  solution  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives. 
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Continuous  Only 

GG  5  Institutionalize  an  Optimizing  Process 


The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  technical  solution 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  technical  solution  process. 
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VALIDATION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Validation  (VAL)  is  to  demonstrate  that  a  product  or 
product  component  fulfills  its  intended  use  when  placed  in  its  intended 
environment. 


Introductory  Notes 


Validation  activities  can  be  applied  to  all  aspects  of  the  product  in  any  of 
its  intended  environments,  such  as  operation,  training,  manufacturing, 
maintenance,  and  support  services.  The  methods  employed  to 
accomplish  validation  can  be  applied  to  work  products  as  well  as  to  the 
product  and  product  components.  (Throughout  the  process  areas, 
where  we  use  the  terms  product  and  product  component,  their  intended 
meanings  also  encompass  services  and  their  components.)  The  work 
products  (e.g.,  requirements,  designs,  and  prototypes)  should  be 
selected  on  the  basis  of  which  are  the  best  predictors  of  how  well  the 
product  and  product  component  will  satisfy  user  needs  and  thus 
validation  is  performed  early  and  incrementally  throughout  the  product 
lifecycle. 

The  validation  environment  should  represent  the  intended  environment 
for  the  product  and  product  components  as  well  as  represent  the 
intended  environment  suitable  for  validation  activities  with  work 
products. 

Validation  demonstrates  that  the  product,  as  provided,  will  fulfill  its 
intended  use;  whereas,  verification  addresses  whether  the  work  product 
properly  reflects  the  specified  requirements.  In  other  words,  verification 
ensures  that  “you  built  it  right”;  whereas,  validation  ensures  that  “you 
built  the  right  thing.”  Validation  activities  use  approaches  similar  to 
verification  (e.g.,  test,  analysis,  inspection,  demonstration,  or 
simulation).  Often,  the  end  users  and  other  relevant  stakeholders  are 
involved  in  the  validation  activities.  Both  validation  and  verification 
activities  often  run  concurrently  and  may  use  portions  of  the  same 
environment. 

Refer  to  the  Verification  process  area  for  more  information  about 
verification  activities. 


Validation  (VAL) 


Whenever  possible,  validation  should  be  accomplished  using  the 
product  or  product  component  operating  in  its  intended  environment. 
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The  entire  environment  can  be  used  or  only  part  of  it.  However, 
validation  issues  can  be  discovered  early  in  the  life  of  the  project  using 
work  products  by  involving  relevant  stakeholders.  Validation  activities 
for  services  can  be  applied  to  work  products  such  as  proposals,  service 
catalogs,  statements  of  work,  and  service  records. 

When  validation  issues  are  identified,  they  are  referred  to  the  processes 
associated  with  the  Requirements  Development,  Technical  Solution,  or 
Project  Monitoring  and  Control  process  areas  for  resolution. 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way: 

•  The  Select  Products  for  Validation  specific  practice  enables  the 
identification  of  the  product  or  product  component  to  be  validated 
and  the  methods  to  be  used  to  perform  the  validation. 

•  The  Establish  the  Validation  Environment  specific  practice  enables 
the  determination  of  the  environment  that  will  be  used  to  carry  out 
the  validation. 

•  The  Establish  Validation  Procedures  and  Criteria  specific  practice 
enables  the  development  of  validation  procedures  and  criteria  that 
are  aligned  with  the  characteristics  of  selected  products,  customer 
constraints  on  validation,  methods,  and  the  validation  environment. 

•  The  Perform  Validation  specific  practice  enables  the  performance  of 
validation  according  to  the  methods,  procedures,  and  criteria. 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  requirements  validation. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
transforming  requirements  into  product  specifications  and  for  corrective 
action  when  validation  issues  are  identified  that  affect  the  product  or 
product  component  design. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  that  the  product  or  product  component  meets  its  requirements. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Validation 

SP  1 .1  Select  Products  for  Validation 
SP  1 .2  Establish  the  Validation  Environment 
SP  1 .3  Establish  Validation  Procedures  and  Criteria 
SG  2  Validate  Product  or  Product  Components 
SP2.1  Perform  Validation 
SP  2.2  Analyze  Validation  Results 
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Specific  Practices  by  Goal 


SGI  Prepare  for  Validation 

Preparation  for  validation  is  conducted. 

Preparation  activities  include  selecting  products  and  product 
components  for  validation  and  establishing  and  maintaining  the 
validation  environment,  procedures,  and  criteria.  The  items  selected  for 
validation  may  include  only  the  product  or  it  may  include  appropriate 
levels  of  the  product  components  that  are  used  to  build  the  product.  Any 
product  or  product  component  may  be  subject  to  validation,  including 
replacement,  maintenance,  and  training  products,  to  name  a  few. 

The  environment  required  to  validate  the  product  or  product  component 
is  prepared.  The  environment  may  be  purchased  or  may  be  specified, 
designed,  and  built.  The  environments  used  for  product  integration  and 
verification  may  be  considered  in  collaboration  with  the  validation 
environment  to  reduce  cost  and  improve  efficiency  or  productivity. 


SP  1.1  Select  Products  for  Validation 

Select  products  and  product  components  to  be  validated  and 
the  validation  methods  that  will  be  used  for  each. 


Products  and  product  components  are  selected  for  validation  on  the 
basis  of  their  relationship  to  user  needs.  For  each  product  component, 
the  scope  of  the  validation  (e.g.,  operational  behavior,  maintenance, 
training,  and  user  interface)  should  be  determined. 


Examples  of  products  and  product  components  that  can  be  validated  include  the 
following: 

•  Product  and  product  component  requirements  and  designs 

•  Product  and  product  components  (e.g.,  system,  hardware  units,  software,  and 
service  documentation) 

•  User  interfaces 

•  User  manuals 

•  Training  materials 

•  Process  documentation 


The  requirements  and  constraints  for  performing  validation  are 
collected.  Then,  validation  methods  are  selected  based  on  their  ability 
to  demonstrate  that  user  needs  are  satisfied.  The  validation  methods 
not  only  define  the  approach  to  product  validation,  but  also  drive  the 
needs  for  the  facilities,  equipment,  and  environments.  This  may  result  in 
the  generation  of  lower  level  product  component  requirements  that  are 
handled  by  the  requirements  development  processes.  Derived 
requirements,  such  as  interface  requirements  to  test  sets  and  test 
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equipment,  can  be  generated.  These  requirements  are  also  passed  to 
the  requirements  development  processes  to  ensure  that  the  product  or 
product  components  can  be  validated  in  an  environment  that  supports 
the  methods. 

Validation  methods  should  be  selected  early  in  the  life  of  the  project  so 
that  they  are  clearly  understood  and  agreed  to  by  the  relevant 
stakeholders. 

The  validation  methods  address  the  development,  maintenance, 
support,  and  training  for  the  product  or  product  component  as 
appropriate. 


:  Examples  of  validation  methods  include  the  following: 

|  •  Discussions  with  the  users,  perhaps  in  the  context  of  a  formal  review 
;  •  Prototype  demonstrations 

i  •  Functional  demonstrations  (e.g.,  system,  hardware  units,  software,  service 
:  documentation,  and  user  interfaces) 

I  •  Pilots  of  training  materials 

:  •  Test  of  products  and  product  components  by  end  users  and  other  relevant 
:  stakeholders 

i  •  Analyses  of  product  and  product  components  (e.g.,  simulations,  modeling,  and 
user  analyses) 


For  Hardware  Engineering 

Hardware  validation  activities  include  modeling  to  validate  form,  fit,  and 
function  of  mechanical  designs;  thermal  modeling;  maintainability  and 
reliability  analysis;  timeline  demonstrations;  and  electrical  design 
simulations  of  electronic  or  mechanical  product  components. 


Typical  Work  Products 

1 .  Lists  of  products  and  product  components  selected  for  validation 

2.  Validation  methods  for  each  product  or  product  component 

3.  Requirements  for  performing  validation  for  each  product  or  product 
component 

4.  Validation  constraints  for  each  product  or  product  component 

Subpractices 

1 .  Identify  the  key  principles,  features,  and  phases  for  product  or 
product  component  validation  throughout  the  life  of  the  project. 

2.  Determine  which  categories  of  user  needs  (operational, 
maintenance,  training,  or  support)  are  to  be  validated. 
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The  product  or  product  component  must  be  maintainable  and  supportable  in  its 
intended  operational  environment.  This  specific  practice  also  addresses  the  actual 
maintenance,  training,  and  support  services  that  may  be  delivered  along  with  the 
product. 


An  example  of  evaluation  of  maintenance  concepts  in  the  operational  environment 
is  a  demonstration  that  maintenance  tools  are  operating  with  the  actual  product. 


3.  Select  the  product  and  product  components  to  be  validated. 

4.  Select  the  evaluation  methods  for  product  or  product  component 
validation. 

5.  Review  the  validation  selection,  constraints,  and  methods  with 
relevant  stakeholders. 


SP  1.2  Establish  the  Validation  Environment 

Establish  and  maintain  the  environment  needed  to  support 
validation. 


The  requirements  for  the  validation  environment  are  driven  by  the 
product  or  product  components  selected,  by  the  type  of  the  work 
products  (e.g.,  design,  prototype,  and  final  version),  and  by  the  methods 
of  validation.  These  may  yield  requirements  for  the  purchase  or 
development  of  equipment,  software,  or  other  resources.  These 
requirements  are  provided  to  the  requirements  development  processes 
for  development.  The  validation  environment  may  include  the  reuse  of 
existing  resources.  In  this  case,  arrangements  for  the  use  of  these 
resources  must  be  made.  Examples  of  the  type  of  elements  in  a 
validation  environment  include  the  following: 

•  Test  tools  interfaced  with  the  product  being  validated  (e.g.,  scope, 
electronic  devices,  and  probes) 

•  Temporary  embedded  test  software 

•  Recording  tools  for  dump  or  further  analysis  and  replay 

•  Simulated  subsystems  or  components  (by  software,  electronics,  or 
mechanics) 

•  Simulated  interfaced  systems  (e.g.,  a  dummy  warship  for  testing  a 
naval  radar) 

•  Real  interfaced  systems  (e.g.,  aircraft  for  testing  a  radar  with 
trajectory  tracking  facilities) 

•  Facilities  and  customer-supplied  products 

•  The  skilled  people  to  operate  or  use  all  the  preceding  elements 

•  Dedicated  computing  or  network  test  environment  (e.g.,  pseudo- 
operational  telecommunications-network  testbed  or  facility  with 
actual  trunks,  switches,  and  systems  established  for  realistic 
integration  and  validation  trials) 
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Early  selection  of  the  products  or  product  components  to  be  validated, 
the  work  products  to  be  used  in  the  validation,  and  the  validation 
methods  is  needed  to  ensure  that  the  validation  environment  will  be 
available  when  necessary. 

The  validation  environment  should  be  carefully  controlled  to  provide  for 
replication,  analysis  of  results,  and  revalidation  of  problem  areas. 

Typical  Work  Products 

1.  Validation  environment 

Subpractices 

1 .  Identify  validation  environment  requirements. 

2.  Identify  customer-supplied  products. 

3.  Identify  reuse  items. 

4.  Identify  test  equipment  and  tools. 

5.  Identify  validation  resources  that  are  available  for  reuse  and 
modification. 

6.  Plan  the  availability  of  resources  in  detail. 


SP  1.3  Establish  Validation  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  validation. 


Validation  procedures  and  criteria  are  defined  to  ensure  that  the  product 
or  product  component  will  fulfill  its  intended  use  when  placed  in  its 
intended  environment.  Acceptance  test  cases  and  procedures  may 
meet  the  need  for  validation  procedures. 

The  validation  procedures  and  criteria  include  test  and  evaluation  of 
maintenance,  training,  and  support  services. 


Examples  of  sources  for  validation  criteria  include  the  following: 

•  Product  and  product  component  requirements 

•  Standards 

•  Customer  acceptance  criteria 

•  Environmental  performance 

•  Thresholds  of  performance  deviation 


Typical  Work  Products 

1.  Validation  procedures 

2.  Validation  criteria 
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3.  Test  and  evaluation  procedures  for  maintenance,  training,  and 
support 

Subpractices 

1 .  Review  the  product  requirements  to  ensure  that  issues  affecting 
validation  of  the  product  or  product  component  are  identified  and 
resolved. 

2.  Document  the  environment,  operational  scenario,  procedures, 
inputs,  outputs,  and  criteria  for  the  validation  of  the  selected 
product  or  product  component. 

3.  Assess  the  design  as  it  matures  in  the  context  of  the  validation 
environment  to  identify  validation  issues. 


SG  2  Validate  Product  or  Product  Components 

The  product  or  product  components  are  validated  to  ensure  that  they  are 
suitable  for  use  in  their  intended  operating  environment. 

The  validation  methods,  procedures,  and  criteria  are  used  to  validate 
the  selected  products  and  product  components  and  any  associated 
maintenance,  training,  and  support  services  using  the  appropriate 
validation  environment.  Validation  activities  are  performed  throughout 
the  product  lifecycle. 


SP  2.1  Perform  Validation 

Perform  validation  on  the  selected  products  and  product 
components. 


To  be  acceptable  to  users,  a  product  or  product  component  must 
perform  as  expected  in  its  intended  operational  environment. 

Validation  activities  are  performed  and  the  resulting  data  are  collected 
according  to  the  established  methods,  procedures,  and  criteria. 

The  as-run  validation  procedures  should  be  documented  and  the 
deviations  occurring  during  the  execution  should  be  noted,  as 
appropriate. 

Typical  Work  Products 

1 .  Validation  reports 

2.  Validation  results 

3.  Validation  cross-reference  matrix 

4.  As-run  procedures  log 

5.  Operational  demonstrations 
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SP  2.2  Analyze  Validation  Results 

Analyze  the  results  of  the  validation  activities. 


The  data  resulting  from  validation  tests,  inspections,  demonstrations,  or 
evaluations  are  analyzed  against  the  defined  validation  criteria.  Analysis 
reports  indicate  whether  the  needs  were  met;  in  the  case  of 
deficiencies,  these  reports  document  the  degree  of  success  or  failure 
and  categorize  probable  cause  of  failure.  The  collected  test,  inspection, 
or  review  results  are  compared  with  established  evaluation  criteria  to 
determine  whether  to  proceed  or  to  address  requirements  or  design 
issues  in  the  requirements  development  or  technical  solution 
processes. 

Analysis  reports  or  as-run  validation  documentation  may  also  indicate 
that  bad  test  results  are  due  to  a  validation  procedure  problem  or  a 
validation  environment  problem. 

Typical  Work  Products 

1.  Validation  deficiency  reports 

2.  Validation  issues 

3.  Procedure  change  request 

Subpractices 

1 .  Compare  actual  results  to  expected  results. 

2.  Based  on  the  established  validation  criteria,  identify  products  and 
product  components  that  do  not  perform  suitably  in  their  intended 
operating  environments,  or  identify  problems  with  the  methods, 
criteria,  and/or  environment. 

3.  Analyze  the  validation  data  for  defects. 

4.  Record  the  results  of  the  analysis  and  identify  issues. 

5.  Use  validation  results  to  compare  actual  measurements  and 
performance  to  intended  use  or  operational  need. 


Generic  Practices  by  Goal 


Continuous  Only 

GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 
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Continuous  Only 

GP  1.1 

Perform  Specific  Practices 

Perform  the  specific  practices  of  the  validation  process  to 
develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  validation  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  selecting 
products  and  product  components  for  validation;  for  selecting  validation 
methods;  and  for  establishing  and  maintaining  validation  procedures, 
criteria,  and  environments  that  ensure  the  products  and  product 
components  satisfy  user  needs  in  their  intended  operating  environment. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  validation 
process. 


Elaboration: 

This  plan  for  performing  the  validation  process  can  be  included  in  (or 
referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area. 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  validation 
process,  developing  the  work  products,  and  providing  the 
services  of  the  process. 


Elaboration: 

Special  facilities  may  be  required  for  validating  the  product  or  product 
components.  When  necessary,  the  facilities  required  for  validation  are 
developed  or  purchased. 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Test-management  tools 

•  Test-case  generators 

•  Test-coverage  analyzers 

•  Simulators 

•  Load,  stress,  and  performance  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  validation  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  validation 
process  as  needed. 

Elaboration: 

:  Examples  of  training  topics  include  the  following: 

;  •  Application  domain 

;  •  Validation  principles,  standards,  and  methods 

•  Intended-use  environment 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  validation  process 
under  appropriate  levels  of  control. 
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Elaboration: 

Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Lists  of  products  and  product  components  selected  for  validation 
I  •  Validation  methods,  procedures,  and  criteria 

j 

:  •  Validation  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  validation 
process  as  planned. 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Selecting  the  products  and  product  components  to  be  validated 

•  Establishing  the  validation  methods,  procedures,  and  criteria 

•  Reviewing  results  of  product  and  product  component  validation  and  resolving 
issues 

•  Resolving  issues  with  the  customers  or  end  users 


Issues  with  the  customers  or  end  users  are  resolved  particularly  when 
there  are  significant  deviations  from  their  baseline  needs  for  the 
following: 

•  Waivers  on  the  contract  or  agreement  (what,  when,  and  for  which 
products) 

•  Additional  in-depth  studies,  trials,  tests,  or  evaluations 

•  Possible  changes  in  the  contracts  or  agreements 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  validation  process  against  the  plan  for 
performing  the  process  and  take  appropriate  corrective  action. 
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Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Number  of  validation  activities  completed  (planned  versus  actual) 

•  Validation  problem  report  trends  (e.g.,  number  written  and  number  closed) 

•  Validation  problem  report  aging  (i.e.,  how  long  each  problem  report  has  been 
open) 

•  Schedule  for  a  specific  validation  activity 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  validation  process 
against  its  process  description,  standards,  and  procedures, 
and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

:  •  Selecting  the  products  and  product  components  to  be  validated 
i  •  Establishing  and  maintaining  validation  methods,  procedures,  and  criteria 

•  Validating  products  or  product  components 

:  Examples  of  work  products  reviewed  include  the  following: 

•  Validation  methods,  procedures,  and  criteria 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  validation 
process  with  higher  level  management  and  resolve  issues. 

Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  validation 
process. 
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GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  validation  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process 
assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Product  component  prototype 

•  Percent  of  time  the  validation  environment  is  available 

•  Number  of  product  defects  found  through  validation  per  development  phase 

•  Validation  analysis  report 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 


The  process  is  institutionalized  as  a  quantitatively  managed  process. 


GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  validation 
process,  which  address  quality  and  process  performance, 
based  on  customer  needs  and  business  objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  validation  process  to  achieve  the 
established  quantitative  quality  and  process-performance 
objectives. 

Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  validation  process  in 
fulfilling  the  relevant  business  objectives  of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  validation  process. 
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VERIFICATION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Verification  (VER)  is  to  ensure  that  selected  work 
products  meet  their  specified  requirements. 


Introductory  Notes 


The  Verification  process  area  involves  the  following:  verification 
preparation,  verification  performance,  and  identification  of  corrective 
action. 

Verification  includes  verification  of  the  product  and  intermediate  work 
products  against  all  selected  requirements,  including  customer,  product, 
and  product  component  requirements.  Throughout  the  process  areas, 
where  we  use  the  terms  product  and  product  component,  their  intended 
meanings  also  encompass  services  and  their  components. 

Verification  is  inherently  an  incremental  process  because  it  occurs 
throughout  the  development  of  the  product  and  work  products, 
beginning  with  verification  of  the  requirements,  progressing  through  the 
verification  of  the  evolving  work  products,  and  culminating  in  the 
verification  of  the  completed  product. 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way: 

•  The  Select  Work  Products  for  Verification  specific  practice  enables 
the  identification  of  the  work  products  to  be  verified,  the  methods  to 
be  used  to  perform  the  verification,  and  the  requirements  to  be 
satisfied  by  each  selected  work  product. 

•  The  Establish  the  Verification  Environment  specific  practice  enables 
the  determination  of  the  environment  that  will  be  used  to  carry  out 
the  verification. 

•  The  Establish  Verification  Procedures  and  Criteria  specific  practice 
then  enables  the  development  of  verification  procedures  and  criteria 
that  are  aligned  with  the  selected  work  products,  requirements, 
methods,  and  characteristics  of  the  verification  environment. 

•  The  Perform  Verification  specific  practice  conducts  the  verification 
according  to  the  available  methods,  procedures,  and  criteria. 
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Verification  of  work  products  substantially  increases  the  likelihood  that 
the  product  will  meet  the  customer,  product,  and  product  component 
requirements. 

The  Verification  and  Validation  process  areas  are  similar,  but  they 
address  different  issues.  Validation  demonstrates  that  the  product,  as 
provided  (or  as  it  will  be  provided),  will  fulfill  its  intended  use,  whereas 
verification  addresses  whether  the  work  product  properly  reflects  the 
specified  requirements.  In  other  words,  verification  ensures  that  “you 
built  it  right”;  whereas,  validation  ensures  that  “you  built  the  right  thing.” 

Peer  reviews  are  an  important  part  of  verification  and  are  a  proven 
mechanism  for  effective  defect  removal.  An  important  corollary  is  to 
develop  a  better  understanding  of  the  work  products  and  the  processes 
that  produced  them  so  that  defects  can  be  prevented  and  process 
improvement  opportunities  can  be  identified. 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers’  peers  to  identify  defects  and  other  changes  that  are  needed. 


Examples  of  peer  review  methods  include  the  following: 

•  Inspections 

•  Structured  walkthroughs 


Related  Process  Areas 


Refer  to  the  Validation  process  area  for  more  information  about 
confirming  that  a  product  or  product  component  fulfills  its  intended  use 
when  placed  in  its  intended  environment. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  the  generation  and  development  of  customer, 
product,  and  product  component  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements. 
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Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Verification 

SP  1 .1  Select  Work  Products  for  Verification 
SP  1 .2  Establish  the  Verification  Environment 
SP  1 .3  Establish  Verification  Procedures  and  Criteria 
SG  2  Perform  Peer  Reviews 

SP2.1  Prepare  for  Peer  Reviews 
SP  2.2  Conduct  Peer  Reviews 

SP  2.3  Analyze  Peer  Review  Data 

SG  3  Verify  Selected  Work  Products 
SP3.1  Perform  Verification 

SP  3.2  Analyze  Verification  Results 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Verification 

Preparation  for  verification  is  conducted. 

Up-front  preparation  is  necessary  to  ensure  that  verification  provisions 
are  embedded  in  product  and  product  component  requirements, 
designs,  developmental  plans,  and  schedules.  Verification  includes 
selection,  inspection,  testing,  analysis,  and  demonstration  of  work 
products. 

Methods  of  verification  include,  but  are  not  limited  to,  inspections,  peer 
reviews,  audits,  walkthroughs,  analyses,  simulations,  testing,  and 
demonstrations.  Practices  related  to  peer  reviews  as  a  specific 
verification  method  are  included  in  specific  goal  2. 

Preparation  also  entails  the  definition  of  support  tools,  test  equipment 
and  software,  simulations,  prototypes,  and  facilities. 

SP  1 .1  Select  Work  Products  for  Verification 

Select  the  work  products  to  be  verified  and  the  verification 
methods  that  will  be  used  for  each. 


Work  products  are  selected  based  on  their  contribution  to  meeting 
project  objectives  and  requirements,  and  to  addressing  project  risks. 

The  work  products  to  be  verified  may  include  those  associated  with 
maintenance,  training,  and  support  services.  The  work  product 
requirements  for  verification  are  included  with  the  verification  methods. 
The  verification  methods  address  the  approach  to  work  product 
verification  and  the  specific  approaches  that  will  be  used  to  verify  that 
specific  work  products  meet  their  requirements. 
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For  Software  Engineering 

Examples  of  verification  methods  include  the  following: 

•  Path  coverage  testing 

•  Load,  stress,  and  performance  testing 

•  Decision-table-based  testing 

•  Functional  decomposition-based  testing 

•  Test-case  reuse 

•  Acceptance  tests 


For  Systems  Engineering 

Verification  for  systems  engineering  typically  includes  prototyping, 
modeling,  and  simulation  to  verify  adequacy  of  system  design  (and 
allocation). 


For  Fiardware  Engineering 

Verification  for  hardware  engineering  typically  requires  a  parametric 
approach  that  considers  various  environmental  conditions  (e.g.,  pressure, 
temperature,  vibration,  and  humidity),  various  input  ranges  (e.g.,  input 
power  could  be  rated  at  20V  to  32V  for  a  planned  nominal  of  28V), 
variations  induced  from  part  to  part  tolerance  issues,  and  many  other 
variables.  Fiardware  verification  normally  tests  most  variables  separately 
except  when  problematic  interactions  are  suspected. 


Selection  of  the  verification  methods  typically  begins  with  involvement  in 
the  definition  of  product  and  product  component  requirements  to  ensure 
that  these  requirements  are  verifiable.  Reverification  should  be 
addressed  by  the  verification  methods  to  ensure  that  rework  performed 
on  work  products  does  not  cause  unintended  defects.  Suppliers  should 
be  involved  in  this  selection  to  ensure  that  the  project's  methods  are 
appropriate  for  the  supplier's  environment. 


IPPD  Addition 

The  verification  methods  should  be  developed  concurrently  and  iteratively 
with  the  product  and  product  component  designs. 


Typical  Work  Products 

1 .  Lists  of  work  products  selected  for  verification 

2.  Verification  methods  for  each  selected  work  product 
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Subpractices 

1 .  Identify  work  products  for  verification. 

2.  Identify  the  requirements  to  be  satisfied  by  each  selected  work 
product. 

Refer  to  the  Maintain  Bidirectional  Traceability  of  Requirements 
specific  practice  in  the  Requirements  Management  process  area  to 
help  identify  the  requirements  for  each  work  product. 

3.  Identify  the  verification  methods  that  are  available  for  use. 

4.  Define  the  verification  methods  to  be  used  for  each  selected  work 
product. 

5.  Submit  for  integration  with  the  project  plan  the  identification  of  work 
products  to  be  verified,  the  requirements  to  be  satisfied,  and  the 
methods  to  be  used. 

Refer  to  the  Project  Planning  process  area  for  information  about 
coordinating  with  project  planning. 


SP  1.2  Establish  the  Verification  Environment 

Establish  and  maintain  the  environment  needed  to  support 
verification. 


An  environment  must  be  established  to  enable  verification  to  take  place. 
The  verification  environment  can  be  acquired,  developed,  reused, 
modified,  ora  combination  of  these,  depending  on  the  needs  of  the 
project. 

The  type  of  environment  required  will  depend  on  the  work  products 
selected  for  verification  and  the  verification  methods  used.  A  peer 
review  may  require  little  more  than  a  package  of  materials,  reviewers, 
and  a  room.  A  product  test  may  require  simulators,  emulators,  scenario 
generators,  data  reduction  tools,  environmental  controls,  and  interfaces 
with  other  systems. 

Typical  Work  Products 

1.  Verification  environment 

Subpractices 

1 .  Identify  verification  environment  requirements. 

2.  Identify  verification  resources  that  are  available  for  reuse  and 
modification. 

3.  Identify  verification  equipment  and  tools. 

4.  Acquire  verification  support  equipment  and  an  environment,  such 
as  test  equipment  and  software. 
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Establish  and  maintain  verification  procedures  and  criteria  for 
the  selected  work  products. 


IPPD  Addition 

The  verification  procedures  and  criteria  should  be  developed  concurrently 
and  iteratively  with  the  product  and  product  component  designs. 


Verification  criteria  are  defined  to  ensure  that  the  work  products  meet 
their  requirements. 

Examples  of  sources  for  verification  criteria  include  the  following: 

•  Product  and  product  component  requirements 

•  Standards 

•  Organizational  policies 

•  Test  type 

•  Test  parameters 

•  Parameters  for  tradeoff  between  quality  and  cost  of  testing 

•  Type  of  work  products 

•  Suppliers 

•  Proposals  and  agreements 


Typical  Work  Products 

1.  Verification  procedures 

2.  Verification  criteria 

Subpractices 

1 .  Generate  the  set  of  comprehensive,  integrated  verification 
procedures  for  work  products  and  any  commercial  off-the-shelf 
products,  as  necessary. 

2.  Develop  and  refine  the  verification  criteria  when  necessary. 

3.  Identify  the  expected  results,  any  tolerances  allowed  in 
observation,  and  other  criteria  for  satisfying  the  requirements. 

4.  Identify  any  equipment  and  environmental  components  needed  to 
support  verification. 
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SG  2  Perform  Peer  Reviews 

Peer  reviews  are  performed  on  selected  work  products. 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers’  peers  to  identify  defects  for  removal  and  to  recommend 
other  changes  that  are  needed. 

The  peer  review  is  an  important  and  effective  verification  method 
implemented  via  inspections,  structured  walkthroughs,  ora  number  of 
other  collegial  review  methods. 

Peer  reviews  are  primarily  applied  to  work  products  developed  by  the 
projects,  but  they  can  also  be  applied  to  other  work  products  such  as 
documentation  and  training  work  products  that  are  typically  developed 
by  support  groups. 


SP  2.1  Prepare  for  Peer  Reviews 

Prepare  for  peer  reviews  of  selected  work  products. 

Preparation  activities  for  peer  reviews  typically  include  identifying  the 
staff  who  will  be  invited  to  participate  in  the  peer  review  of  each  work 
product;  identifying  the  key  reviewers  who  must  participate  in  the  peer 
review;  preparing  and  updating  any  materials  that  will  be  used  during 
the  peer  reviews,  such  as  checklists  and  review  criteria,  and  scheduling 
peer  reviews. 

Typical  Work  Products 

1 .  Peer  review  schedule 

2.  Peer  review  checklist 

3.  Entry  and  exit  criteria  for  work  products 

4.  Criteria  for  requiring  another  peer  review 

5.  Peer  review  training  material 

6.  Selected  work  products  to  be  reviewed 

Subpractices 

1 .  Determine  what  type  of  peer  review  will  be  conducted. 

Examples  of  types  of  peer  reviews  include  the  following: 

|  •  Inspections 
|  •  Structured  walkthroughs 
:  •  Active  reviews 
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2.  Define  requirements  for  collecting  data  during  the  peer  review. 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  identifying  and  collecting  data. 

3.  Establish  and  maintain  entry  and  exit  criteria  for  the  peer  review. 

4.  Establish  and  maintain  criteria  for  requiring  another  peer  review. 

5.  Establish  and  maintain  checklists  to  ensure  that  the  work  products 

are  reviewed  consistently. 


Examples  of  items  addressed  by  the  checklists  include  the  following: 

:  •  Rules  of  construction 
i  •  Design  guidelines 
|  •  Completeness 
i  •  Correctness 
i  •  Maintainability 
•  Common  defect  types 

The  checklists  are  modified  as  necessary  to  address  the  specific  type  of  work 
product  and  peer  review.  The  peers  of  the  checklist  developers  and  potential 
users  review  the  checklists. 

6.  Develop  a  detailed  peer  review  schedule,  including  the  dates  for 
peer  review  training  and  for  when  materials  for  peer  reviews  will  be 
available. 

7.  Ensure  that  the  work  product  satisfies  the  peer  review  entry  criteria 
prior  to  distribution. 

8.  Distribute  the  work  product  to  be  reviewed  and  its  related 
information  to  the  participants  early  enough  to  enable  participants 
to  adequately  prepare  for  the  peer  review. 

9.  Assign  roles  for  the  peer  review  as  appropriate. 


Examples  of  roles  include  the  following: 

•  Leader 

•  Reader 

•  Recorder 

•  Author 


1 0.  Prepare  for  the  peer  review  by  reviewing  the  work  product  prior  to 
conducting  the  peer  review. 
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SP  2.2  Conduct  Peer  Reviews 

Conduct  peer  reviews  on  selected  work  products  and  identify 
issues  resulting  from  the  peer  review. 


One  of  the  purposes  of  conducting  a  peer  review  is  to  find  and  remove 
defects  early.  Peer  reviews  are  performed  incrementally  as  work 
products  are  being  developed.  These  reviews  are  structured  and  are 
not  management  reviews. 

Peer  reviews  may  be  performed  on  key  work  products  of  specification, 
design,  test,  and  implementation  activities  and  specific  planning  work 
products. 

The  focus  of  the  peer  review  should  be  on  the  work  product  in  review, 
not  on  the  person  who  produced  it. 

When  issues  arise  during  the  peer  review,  they  should  be 
communicated  to  the  primary  developer  of  the  work  product  for 
correction. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  information 
about  tracking  issues  that  arise  during  a  peer  review. 

Peer  reviews  should  address  the  following  guidelines:  there  must  be 
sufficient  preparation,  the  conduct  must  be  managed  and  controlled, 
consistent  and  sufficient  data  must  be  recorded  (an  example  is 
conducting  a  formal  inspection),  and  action  items  must  be  recorded. 

Typical  Work  Products 

1 .  Peer  review  results 

2.  Peer  review  issues 

3.  Peer  review  data 

Subpractices 

1 .  Perform  the  assigned  roles  in  the  peer  review. 

2.  Identify  and  document  defects  and  other  issues  in  the  work 
product. 

3.  Record  the  results  of  the  peer  review,  including  the  action  items. 

4.  Collect  peer  review  data. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  data  collection. 

5.  Identify  action  items  and  communicate  the  issues  to  relevant 
stakeholders. 

6.  Conduct  an  additional  peer  review  if  the  defined  criteria  indicate  the 
need. 

7.  Ensure  that  the  exit  criteria  for  the  peer  review  are  satisfied. 
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SP  2.3  Analyze  Peer  Review  Data 

Analyze  data  about  preparation,  conduct,  and  results  of  the 
peer  reviews. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 

information  about  obtaining  and  analyzing  data. 

Typical  Work  Products 

1 .  Peer  review  data 

2.  Peer  review  action  items 

Subpractices 

1 .  Record  data  related  to  the  preparation,  conduct,  and  results  of  the 
peer  reviews. 

Typical  data  are  product  name,  product  size,  composition  of  the  peer  review  team, 
type  of  peer  review,  preparation  time  per  reviewer,  length  of  the  review  meeting, 
number  of  defects  found,  type  and  origin  of  defect,  and  so  on.  Additional 
information  on  the  work  product  being  peer  reviewed  may  be  collected,  such  as 
size,  development  stage,  operating  modes  examined,  and  requirements  being 
evaluated. 

2.  Store  the  data  for  future  reference  and  analysis. 

3.  Protect  the  data  to  ensure  that  peer  review  data  are  not  used 
inappropriately. 


Examples  of  inappropriate  use  of  peer  review  data  include  using  data  to  evaluate 
the  performance  of  people  and  using  data  for  attribution. 


4.  Analyze  the  peer  review  data. 


Examples  of  peer  review  data  that  can  be  analyzed  include  the  following: 

•  Phase  defect  was  injected 

•  Preparation  time  or  rate  versus  expected  time  or  rate 

•  Number  of  defects  versus  number  expected 

•  Types  of  defects  detected 

•  Causes  of  defects 

•  Defect  resolution  impact 
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SG  3  Verify  Selected  Work  Products 

Selected  work  products  are  verified  against  their  specified  requirements. 

The  verification  methods,  procedures,  and  criteria  are  used  to  verify  the 
selected  work  products  and  any  associated  maintenance,  training,  and 
support  services  using  the  appropriate  verification  environment. 
Verification  activities  should  be  performed  throughout  the  product 
lifecycle.  Practices  related  to  peer  reviews  as  a  specific  verification 
method  are  included  in  specific  goal  2. 


SP  3.1  Perform  Verification 

Perform  verification  on  the  selected  work  products. 


Verifying  products  and  work  products  incrementally  promotes  early 
detection  of  problems  and  can  result  in  the  early  removal  of  defects. 
The  results  of  verification  save  considerable  cost  of  fault  isolation  and 
rework  associated  with  troubleshooting  problems. 

Typical  Work  Products 

1 .  Verification  results 

2.  Verification  reports 

3.  Demonstrations 

4.  As-run  procedures  log 

Subpractices 

1 .  Perform  verification  of  selected  work  products  against  their 
requirements. 

2.  Record  the  results  of  verification  activities. 

3.  Identify  action  items  resulting  from  verification  of  work  products. 

4.  Document  the  “as-run”  verification  method  and  the  deviations  from 
the  available  methods  and  procedures  discovered  during  its 
performance. 


SP  3.2  Analyze  Verification  Results 

Analyze  the  results  of  all  verification  activities. 


Actual  results  must  be  compared  to  established  verification  criteria  to 
determine  acceptability. 

The  results  of  the  analysis  are  recorded  as  evidence  that  verification 
was  conducted. 
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For  each  work  product,  all  available  verification  results  are 
incrementally  analyzed  to  ensure  that  the  requirements  have  been  met. 
Since  a  peer  review  is  one  of  several  verification  methods,  peer  review 
data  should  be  included  in  this  analysis  activity  to  ensure  that  the 
verification  results  are  analyzed  sufficiently.  Analysis  reports  or  “as-run” 
method  documentation  may  also  indicate  that  bad  verification  results 
are  due  to  method  problems,  criteria  problems,  or  a  verification 
environment  problem. 

Typical  Work  Products 

1.  Analysis  report  (e.g.,  statistics  on  performances,  causal  analysis  of 
nonconformances,  comparison  of  the  behavior  between  the  real 
product  and  models,  and  trends) 

2.  Trouble  reports 

3.  Change  requests  for  the  verification  methods,  criteria,  and 
environment 

Subpractices 

1 .  Compare  actual  results  to  expected  results. 

2.  Based  on  the  established  verification  criteria,  identify  products  that 
have  not  met  their  requirements  or  identify  problems  with  the 
methods,  procedures,  criteria,  and  verification  environment 

3.  Analyze  the  verification  data  on  defects. 

4.  Record  all  results  of  the  analysis  in  a  report. 

5.  Use  verification  results  to  compare  actual  measurements  and 
performance  to  technical  performance  parameters. 

6.  Provide  information  on  how  defects  can  be  resolved  (including 
verification  methods,  criteria,  and  verification  environment)  and 
initiate  corrective  action. 

Refer  to  the  corrective  action  practices  of  Project  Monitoring  and 
Control  process  area  for  more  information  about  implementing 
corrective  action. 
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Generic  Practices  by  Goal 


Continuous  Only 

GG  1 

Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 

GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  verification  process  to 
develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area. 

GG  2 

Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

Staged  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
staged  representation. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  verification  process. 


Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  verification  methods,  procedures,  criteria,  and  the 
verification  environment,  as  well  as  for  performing  peer  reviews  and 
verifying  selected  work  products. 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  verification 
process. 
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Elaboration: 

This  plan  for  performing  the  verification  process  can  be  included  in  (or 
referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  verification 
process,  developing  the  work  products,  and  providing  the 
services  of  the  process. 


Elaboration: 

Special  facilities  may  be  required  for  verifying  selected  work  products. 
When  necessary,  the  facilities  required  for  the  activities  in  the 
Verification  process  area  are  developed  or  purchased. 


Certain  verification  methods  may  require  special  tools,  equipment, 
facilities,  and  training  (e.g.,  peer  reviews  may  require  meeting  rooms 
and  trained  moderators;  and  certain  verification  tests  may  require 
special  test  equipment  and  people  skilled  in  the  use  of  the  equipment). 


Examples  of  other  resources  provided  include  the  following  tools: 

•  Test  management  tools 

•  Test-case  generators 

•  Test-coverage  analyzers 

•  Simulators 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  verification  process. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  verification 
process  as  needed. 
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Elaboration: 

:  Examples  of  training  topics  include  the  following: 

I  •  Application  or  service  domain 

I  •  Verification  principles,  standards,  and  methods  (e.g.,  analysis,  demonstration, 
:  inspection,  and  test) 

:  •  Verification  tools  and  facilities 

i  •  Peer  review  preparation  and  procedures 

:  •  Meeting  facilitation 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  verification  process 
under  appropriate  levels  of  control. 

Elaboration: 

'  Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Verification  procedures  and  criteria 
:•  Peer  review  training  material 

:  •  Peer  review  data 

•  Verification  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  verification 
process  as  planned. 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process. 


Examples  of  activities  for  stakeholder  involvement  include  the  following: 

•  Selecting  work  products  and  methods  for  verification 

•  Establishing  verification  procedures  and  criteria 

•  Conducting  peer  reviews 

•  Assessing  verification  results  and  identifying  corrective  action 
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GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  verification  process  against  the  plan  for 
performing  the  process  and  take  appropriate  corrective  action. 


Elaboration: 


Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include 
the  following: 

•  Verification  profile  (e.g.,  the  number  of  verifications  planned  and  performed,  and 
the  defects  found;  or  perhaps  categorized  by  verification  method  or  type) 

•  Number  of  defects  detected  by  defect  category 

•  Verification  problem  report  trends  (e.g.,  number  written  and  number  closed) 

•  Verification  problem  report  status  (i.e.,  how  long  each  problem  report  has  been 
open) 

•  Schedule  for  a  specific  verification  activity 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  verification  process 
against  its  process  description,  standards,  and  procedures, 
and  address  noncompliance. 

Elaboration: 

Examples  of  activities  reviewed  include  the  following: 

i  •  Selecting  work  products  for  verification 
i  •  Establishing  and  maintaining  verification  procedures  and  criteria 
I  •  Performing  peer  reviews 
•  Verifying  selected  work  products 

Examples  of  work  products  reviewed  include  the  following: 

I  •  Verification  procedures  and  criteria 
:  •  Peer  review  checklists 

j 

:  •  Verification  reports 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  verification 
process  with  higher  level  management  and  resolve  issues. 
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Continuous  Only 

GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

This  generic  goal's  appearance  here  reflects  its  location  in  the 
continuous  representation. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  verification 
process. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  verification  process  to  support  the  future  use 
and  improvement  of  the  organization’s  processes  and  process 
assets. 


Elaboration: 


Examples  of  work  products,  measures,  measurement  results,  and  improvement 
information  include  the  following: 

•  Peer  review  records  that  include  conduct  time  and  average  preparation  time 

•  Number  of  product  defects  found  through  verification  per  development  phase 

•  Verification  and  analysis  report 


Continuous  Only 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
verification  process,  which  address  quality  and  process 
performance,  based  on  customer  needs  and  business 
objectives. 

GP  4.2 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  verification  process  to  achieve  the 
established  quantitative  quality  and  process-performance 
objectives. 
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Continuous  Only 

GG  5  Institutionalize  an  Optimizing  Process 


The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  verification  process  in 
fulfilling  the  relevant  business  objectives  of  the  organization. 

GP  5.2 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  verification  process. 

Verification  (VER) 


513 


CMMI  for  Development 
Version  1.2 


514 


Verification  (VER) 


CMMI  for  Development 
Version  1.2 


Part  Three 

The  Appendices  and  Glossary 


The  Appendices  and  Glossary 


515 


CMMI  for  Development 
Version  1.2 


516 


The  Appendices  and  Glossary 


CMMI  for  Development 
Version  1.2 


A.  References 


Publicly  Available  Sources 


Ahern  2003 


Ahern  2005 


Chrissis  2003 


Crosby  1979 


Curtis  2002 


Deming  1986 


DoD  1996 


Dymond  2004 


EIA1994 


Ahern,  Dennis  M.;  Clouse,  Aaron;  &  Turner,  Richard.  CMMI 
Distilled:  A  Practical  Introduction  to  Integrated  Process 
Improvement,  Second  Edition.  Boston:  Addison-Wesley, 
2003. 

Ahern,  Dennis  M.;  Armstrong,  Jim;  Clouse,  Aaron; 

Ferguson,  Jack  R.;  Hayes,  Will;  &  Nidiffer,  Kenneth  E.  CMMI 
SCAMPI  Distilled:  Appraisals  for  Process  Improvement. 
Boston:  Addison-Wesley,  2005. 

Chrissis,  Mary  Beth;  Konrad,  Mike;  &  Shrum,  Sandy.  CMMI: 
Guidelines  for  Process  Integration  and  Product 
Improvement.  Boston:  Addison-Wesley,  2003. 

Crosby,  Philip  B.  Quality  Is  Free  The  Art  of  Making  Quality 
Certain.  New  York:  McGraw-Hill,  1979. 

Curtis,  Bill;  Hefley,  William  E.;  &  Miller,  Sally  A.  The  People 
Capability  Maturity  Model  Guidelines  for  Improving  the 
Workforce.  Boston:  Addison-Wesley,  2002. 

Deming,  W.  Edwards.  Out  of  the  Crisis.  Cambridge,  MA: 

MIT  Center  for  Advanced  Engineering,  1986. 

Department  of  Defense.  DoD  Guide  to  Integrated  Product 
and  Process  Development  (Version  1.0).  Washington,  DC: 
Office  of  the  Under  Secretary  of  Defense  (Acquisition  and 
Technology),  February  5,  1996. 

http://www.abm.rda.hq.navy.mil/navyaos/content/download/ 

1 000/4448/file/ippdhdbk.pdf. 

Dymond,  Kenneth  M.  A  Guide  to  the  CMMI:  Interpreting  the 
Capability  Maturity  Model  Integration.  Annapolis,  MD: 
Process  Transition  International  Inc.,  2004. 

Electronic  Industries  Alliance.  El  A  Interim  Standard: 

Systems  Engineering  (EIA/IS-632).  Washington,  DC,  1994. 


References 


517 


CMMI  for  Development 
Version  1.2 

EIA1998 


GEIA2004 


Gibson  2006 


Humphrey  1989 

IEEE  1990 

ISO  1987 

ISO  1995 

ISO  1998 

ISO  2000 

ISO  2002a 


Electronic  Industries  Alliance.  Systems  Engineering 
Capability  Model  (EIA/IS-731).  Washington,  DC,  1998; 

(Note:  This  model  has  been  retired  by  EIA.) 

Government  Electronic  Industries  Alliance.  Data 
Management  (GEIA-859).  Washington,  DC,  2004. 
http://webstore.ansi.org/ansidocstore/product.asp?sku=GEI 
A-859-2004. 

Gibson,  Diane  L.;  Goldenson,  Dennis  R.  &  Kost,  Keith. 
Performance  Results  of  CMMI-Based  Process 
Improvement.  (CMU/SEI-2006-TR-004,  ESC-TR-2006-004). 
Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie 
Mellon  University,  August  2006. 

http://www.sei.cmu.edU/publications/documents/06.reports/0 

6tr004.html. 

Humphrey,  Watts  S.  Managing  the  Software  Process. 
Reading,  MA:  Addison-Wesley,  1989. 

Institute  of  Electrical  and  Electronics  Engineers.  IEEE 
Standard  Computer  Dictionary:  A  Compilation  of  IEEE 
Standard  Computer  Glossaries.  New  York:  IEEE,  1990. 

International  Organization  for  Standardization.  ISO  9000: 

International  Standard.  1987. 

http://www.iso.ch/. 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  TR 
12207  Information  Technology — Software  Life  Cycle 
Processes,  1995. 
http://www.jtd-sc7.org. 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  TR 
15504  Information  Technology — Software  Process 
Assessment,  1998. 
http://www.iso.ch/. 

International  Organization  for  Standardization.  ISO  9001, 
Quality  Management  Systems — Requirements,  2000. 
http://www.iso.ch/. 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  15939 
Software  Engineering — Software  Measurement  Process, 
2002. 

http://www.iso.ch/. 


518 


References 


CMMI  for  Development 
Version  1.2 


ISO  2002b 


ISO  2006 


Juran  1988 

McGarry  2000 

SEI  1995 

SEI  1997a 

SEI  1997b 

SEI  2001 


International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  15288 
Systems  Engineering — System  Life  Cycle  Processes,  2002. 
http://www.jtd-sc7.org/. 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  TR 
15504  Information  Technology — Software  Process 
Assessment  Part  1:  Concepts  and  Vocabulary,  Part  2: 
Performing  an  Assessment,  Part  3:  Guidance  on  Performing 
an  Assessment,  Part  4:  Guidance  on  Use  for  Process 
Improvement  and  Process  Capability  Determination,  Part  5: 
An  Exemplar  Process  Assessment  Model,  2003-2006. 
http://www.jtd-sc7.org/. 

Juran,  Joseph  M.  Juran  on  Planning  for  Quality.  New  York: 
Macmillan,  1988. 

McGarry,  John;  Card,  David;  Jones,  Cheryl;  Layman,  Beth; 
Clark,  Elizabeth;  Dean,  Joseph;  &  Hall,  Fred.  Practical 
Software  Measurement:  Objective  Information  for  Decision 
Makers.  Boston:  Addison-Wesley,  2002. 

Software  Engineering  Institute.  The  Capability  Maturity 
Model:  Guidelines  for  Improving  the  Software  Process. 
Reading,  MA:  Addison-Wesley,  1995. 

Integrated  Product  Development  Capability  Maturity  Model, 
Draft  Version  0.98.  Pittsburgh,  PA:  Enterprise  Process 
Improvement  Collaboration  and  Software  Engineering 
Institute,  Carnegie  Mellon  University,  July  1997. 

(Note:  This  model  was  never  officially  released  and  is  no 
longer  publicly  available.) 

Software  Engineering  Institute.  Software  CMM,  Version  2.0 
(Draft  C),  October  22,  1997. 

(Note:  This  model  was  never  officially  released  and  is  no 
longer  publicly  available.) 

Paulk,  Mark  C.  &  Chrissis,  Mary  Beth.  The  2001  High 
Maturity  Workshop  (CMU/SEI-2001-SR-014).  Pittsburgh, 

PA:  Software  Engineering  Institute,  Carnegie  Mellon 
University,  January  2002. 

http://www.sei.cmu.edu/publications/documents/01  .reports/0 
1sr014.html. 


References 


519 


CMMI  for  Development 
Version  1.2 


SEI  2002a 


SEI  2002b 


SEI  2002c 


SEI  2004 


SEI  2005 


SEI  2006a 


CMMI  Product  Development  Team.  CMMI  for  Systems 
Engineering/Software  Engineering/Integrated  Product  and 
Process  Development/Supplier  Sourcing,  Version  1.1 
Staged  Representation  (CMU/SEI-2002-TR-012,  ESC-TR- 
2002-012).  Pittsburgh,  PA:  Software  Engineering  Institute, 
Carnegie  Mellon  University,  March  2002. 
http://www.sei.cmu.edU/publications/documents/02.reports/0 
2tr012.html. 

CMMI  Product  Development  Team.  CMMI  for  Systems 
Engineering/Software  Engineering/Integrated  Product  and 
Process  Development/Supplier  Sourcing,  Version  1.1 
Continuous  Representation  (CMU/SEI-2002-TR-01 1 ,  ESC- 
TR-2002-01 1).  Pittsburgh,  PA:  Software  Engineering 
Institute,  Carnegie  Mellon  University,  March  2002. 
http://www.sei.cmu.edU/publications/documents/02.reports/0 
2tr011.html. 

Software  Engineering  Institute.  Software  Acquisition 
Capability  Maturity  Model  (SA-CMM)  Version  1.03 
(CMU/SEI-2002-TR-01 0,  ESC-TR-2002-01 0).  Pittsburgh, 

PA:  Software  Engineering  Institute,  Carnegie  Mellon 
University,  March  2002. 

http://www.sei.cmu.edU/publications/documents/02.reports/0 

2tr010.html. 

Software  Engineering  Institute.  CMMI  A-Specification, 
Version  1.6. 

http://www.sei.cmu.edu/cmmi/background/aspec.html 
(February  2004). 

Software  Engineering  Institute.  CMMI  Acquisition  Module 
(CMMI-AM)  Version  1.1  (CMU/SEI-2005-TR-01 1). 

Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie 
Mellon  University,  May  2005. 

http://www.sei.cmu.edU/publications/documents/05.reports/0 
5tr011/05tr0 11.html. 

CMMI  Product  Development  Team.  ARC  vl.2,  Appraisal 
Requirements  for  CMMI,  Version  1 .2  (CMU/SEI-2006-TR- 
011).  Pittsburgh,  PA:  Software  Engineering  Institute, 
Carnegie  Mellon  University,  July  2006. 
http://www.sei.cmu.edu/publications/documents/01  .reports/0 
6tr011.html. 


520 


References 


CMMI  for  Development 
Version  1.2 


SEI  2006b  CMMI  Product  Development  Team.  SCAMPI  vl.2,  Standard 

CMMI  Appraisal  Method  for  Process  Improvement,  Version 
1.2:  Method  Definition  Document  (CMU/SEI-2006-HB-002). 
Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie 
Mellon  University,  July  2006. 

http://www.sei.cmu.edU/publications/documents/06.reports/0 

6hb002.html. 

Shewhart  1931  Shewhart,  Walter  A.  Economic  Control  of  Quality  of 

Manufactured  Product.  New  York:  Van  Nostrand,  1931. 


Regularly  Updated  Sources 


SEI  1  Software  Engineering  Institute.  The  IDEAL  Model. 

http://www.sei.cmu.edu/ideal/ideal.html. 

SEI  2  Software  Engineering  Institute.  CMMI  Frequently  Asked 

Questions  (FAQs). 

http://www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html. 

SEI  3  Software  Engineering  Institute.  CMMI  Performance  Results. 

http://www.sei.cmu.edu/cmmi/results.html. 


References 


521 


CMMI  for  Development 
Version  1.2 


B.  Acronyms 


API 

application  program  interface 

ARC 

Appraisal  Requirements  for  CMMI 

CAD 

computer-aided  design 

CAR 

Causal  Analysis  and  Resolution  (process  area) 

CCB 

configuration  control  board 

CL 

capability  level 

CM 

Configuration  Management  (process  area) 

CMM 

Capability  Maturity  Model 

CMMI 

Capability  Maturity  Model  Integration 

CMMI-DEV 

CMMI  for  Development 

CMMI-DEV+IPPD 

CMMI  for  Development  +IPPD 

COTS 

commercial  off  the  shelf 

CPI 

cost  performance  index 

CPM 

critical  path  method 

CSCI 

computer  software  configuration  item 

DAR 

Decision  Analysis  and  Resolution  (process  area) 

DoD 

Department  of  Defense 

EIA 

Electronic  Industries  Alliance 

EIA/IS 

Electronic  Industries  Alliance/Interim  Standard 

EPG 

engineering  process  group 

FCA 

functional  configuration  audit 
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GG 

GP 

IBM 

IDEAL 

IEEE 

INCOSE 

IPD-CMM 

IPM 

IPM+IPPD 

IPPD 

ISO 

ISO/IEC 

MA 

MDD 

ML 

NDI 

NDIA 

OID 

OPD 

OPD+IPPD 

OPF 

OPP 

OT 

OUSD  (AT&L) 


generic  goal 
generic  practice 

International  Business  Machines 

Initiating,  Diagnosing,  Establishing,  Acting,  Learning 

Institute  of  Electrical  and  Electronics  Engineers 

International  Council  on  Systems  Engineering 

Integrated  Product  Development  Capability  Maturity  Model 

Integrated  Project  Management  (process  area) 

Integrated  Project  Management  +IPPD  (process  area) 

integrated  product  and  process  development 

International  Organization  for  Standardization 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission 

Measurement  and  Analysis  (process  area) 

Method  Definition  Document 

maturity  level 

nondevelopmental  item 

National  Defense  Industrial  Association 

Organizational  Innovation  and  Deployment  (process  area) 

Organizational  Process  Definition  (process  area) 

Organizational  Process  Definition  +IPPD  (process  area) 

Organizational  Process  Focus  (process  area) 

Organizational  Process  Performance  (process  area) 

Organizational  Training  (process  area) 

Office  of  the  Under  Secretary  of  Defense  (Acquisition, 
Technology,  and  Logistics) 
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P-CMM 

People  Capability  Maturity  Model 

PA 

process  area 

PCA 

physical  configuration  audit 

PERT 

Program  Evaluation  and  Review  Technique 

PI 

Product  Integration  (process  area) 

PMC 

Project  Monitoring  and  Control  (process  area) 

PP 

Project  Planning  (process  area) 

PPQA 

Process  and  Product  Quality  Assurance  (process  area) 

QA 

quality  assurance 

QFD 

Quality  Function  Deployment 

QPM 

Quantitative  Project  Management  (process  area) 

RD 

Requirements  Development  (process  area) 

REQM 

Requirements  Management  (process  area) 

ROI 

return  on  investment 

RSKM 

Risk  Management  (process  area) 

SA-CMM 

Software  Acquisition  Capability  Maturity  Model 

SAM 

Supplier  Agreement  Management  (process  area) 

SCAMPI 

Standard  CMMI  Appraisal  Method  for  Process 
Improvement 

SECM 

Systems  Engineering  Capability  Model 

SEI 

Software  Engineering  Institute 

SG 

specific  goal 

SP 

specific  practice 

SPI 

schedule  performance  index 

SW-CMM 

Capability  Maturity  Model  for  Software  or  Software 
Capability  Maturity  Model 
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TS 

Technical  Solution  (process  area) 

URL 

uniform  resource  locator 

VAL 

Validation  (process  area) 

VER 

Verification  (process  area) 

WBS 

work  breakdown  structure 
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C.  CMMI  for  Development  Project  Participants 


Many  talented  people  have  been  part  of  the  product  team  that  has 
created  and  maintained  the  CMMI  Product  Suite  since  its  inception. 

This  appendix  recognizes  the  people  involved  in  the  update  of  CMMI  for 
the  version  1 .2  release.  The  four  primary  groups  involved  in  this 
development  were  the  Product  Team,  Sponsors,  Steering  Group,  and 
Configuration  Control  Board.  Current  members  of  these  groups  are 
listed.  If  you  wish  to  see  a  more  complete  listing  of  participants  from 
previous  years,  see  Appendix  C  of  the  version  1.1  models. 


Product  Team 


The  Product  Team  reviewed  change  requests  submitted  by  CMMI  users 
to  change  the  CMMI  Product  Suite,  including  the  framework,  models, 
training,  and  appraisal  materials.  Development  activities  were  based  on 
change  requests,  version  1 .2  guidelines  provided  by  the  Steering 
Group,  and  input  from  Configuration  Control  Board  members. 

The  program  manager  for  the  version  1 .2  release  was  Mike  Phillips.  He 
coordinated  the  efforts  of  the  following  teams. 


Model  Team  Members 

•  Armstrong,  Jim  (Systems  and  Software  Consortium) 

•  Bate,  Roger  (Software  Engineering  Institute) 

•  Cepeda,  Sandra  (RD&E  Command,  Software  Engineering 
Directorate) 

•  Chrissis,  Mary  Beth  (Software  Engineering  Institute) 

•  Clouse,  Aaron  (Raytheon) 

•  D'Ambrosa,  Mike  (BAE  Systems) 

•  Hollenbach,  Craig  (Northrop  Grumman) 

•  Konrad,  Mike  (Software  Engineering  Institute)15 

•  Norimatsu,  So  (Norimatsu  Process  Engineering  Laboratory,  Inc.) 

•  Richter,  Karen  (Institute  for  Defense  Analyses) 

•  Shrum,  Sandy  (Software  Engineering  Institute) 


15  Team  Leader 
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SCAMPI  Upgrade  Team  Members 

•  Busby,  Mary  (Lockheed  Martin)16 

•  Cepeda,  Sandra  (RD&E  Command,  Software  Engineering 
Directorate) 

•  Ferguson,  Jack  (Software  Engineering  Institute)16 

•  Hayes,  Will  (Software  Engineering  Institute) 

•  Heil,  James  (U.S.  Army)  in  memoriam 

•  Kirkham,  Denise  (Boeing) 

•  Masters,  Steve  (Software  Engineering  Institute) 

•  Ming,  Lisa  (BAE  Systems) 

•  Ryan,  Charlie  (Software  Engineering  Institute) 

•  Sumpter,  Beth  (National  Security  Agency) 

•  Ulrich,  Ron  (Northrop  Grumman) 

•  Wickless,  Joe  (Software  Engineering  Institute) 

Training  Team  Members 

•  Chrissis,  Mary  Beth  (Software  Engineering  Institute) 

•  Gibson,  Diane  (Software  Engineering  Institute) 

•  Knorr,  Georgeann  (Software  Engineering  Institute) 

•  Kost,  Keith  (Software  Engineering  Institute) 

•  Matthews,  Jeanne  (Software  Engineering  Institute) 

•  Shrum,  Sandy  (Software  Engineering  Institute) 

•  Svolou,  Agapi  (Software  Engineering  Institute) 

•  Tyson,  Barbara  (Software  Engineering  Institute)17 

•  Wickless,  Joe  (Software  Engineering  Institute) 

•  Wolf,  Gary  (Raytheon) 

Architecture  Team  Members 

•  Bate,  Roger  (Software  Engineering  Institute) 

•  Chrissis,  Mary  Beth  (Software  Engineering  Institute) 

•  Hoffman,  Hubert  (General  Motors) 

•  Hollenbach,  Craig  (Northrop  Grumman) 

•  Ming,  Lisa  (BAE  Systems) 


16  Co-Team  Leaders 

17  Team  Leader 
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•  Phillips,  Mike  (Software  Engineering  Institute)18 

•  Scibilia,  John  (U.S.  Army) 

•  Wilson,  Hal  (Northrop  Grumman) 

•  Wolf,  Gary  (Raytheon) 

Hardware  Team  Members 

•  Armstrong,  Jim  (Systems  and  Software  Consortium) 

•  Bishop,  Jamie  (Lockheed  Martin) 

•  Cattan,  Denise  (Spirula) 

•  Clouse,  Aaron  (Raytheon) 

•  Connell,  Clifford  (Raytheon) 

•  Fisher,  Jerry  (Aerospace  Corporation) 

•  Hertneck,  Christian  (Siemens) 

•  Nussbaum,  Winfried  (Siemens) 

•  Phillips,  Mike  (Software  Engineering  Institute)19 

•  Zion,  Christian  (THALES) 

Piloting  Team  Members 

•  Brown,  Rhonda  (Software  Engineering  Institute)20 

•  Chrissis,  Mary  Beth  (Software  Engineering  Institute) 

•  Ferguson,  Jack  (Software  Engineering  Institute) 

•  Konrad,  Mike  (Software  Engineering  Institute) 

•  Phillips,  Marilyn  (Q-Labs,  Inc.) 

•  Phillips,  Mike  (Software  Engineering  Institute)20 

•  Tyson,  Barbara  (Software  Engineering  Institute) 

Quality  Team  Members 

•  Brown,  Rhonda  (Software  Engineering  Institute)21 

•  Kost,  Keith  (Software  Engineering  Institute) 

•  McSteen,  Bill  (Software  Engineering  Institute) 

•  Shrum,  Sandy  (Software  Engineering  Institute) 


18  Team  Leader 

19  Team  Leader 

20  Co-Team  Leaders 

21  Team  Leader 
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Sponsors 


The  CMMI  version  1.2  project  was  sponsored  by  both  government  and 
industry.  Government  sponsorship  was  provided  by  the  U.S. 
Department  of  Defense  (DoD),  specifically  the  Office  of  the  Under 
Secretary  of  Defense  (Acquisition,  Technology,  and  Logistics)  (OUSD 
[AT&L]).  Industry  sponsorship  was  provided  by  the  Systems 
Engineering  Committee  of  the  National  Defense  Industrial  Association 
(NDIA). 

•  Rassa,  Bob  (NDIA  Systems  Engineering  Division) 

•  Schaeffer,  Mark  (OUSD  [AT&L]) 


Steering  Group 


The  Steering  Group  has  guided  and  approved  the  plans  of  the  version 
1.2  Product  Team,  provided  consultation  on  significant  CMMI  project 
issues,  and  ensured  involvement  from  a  variety  of  interested 
communities. 

Steering  Group  Members 

•  Baldwin,  Kristen  (OUSD  [AT&L]  DS/SE) 

•  Chittister,  Clyde  (Software  Engineering  Institute) 

•  D'Agosto,  Tony  (U.S.  Army  RDECOM-ARDEC) 

•  Gill,  Jim  (Boeing  Integrated  Defense  Systems) 

•  Kelly,  John  (NASA  HQ) 

•  Lundeen,  Kathy  (Defense  Contract  Management  Agency) 

•  McCarthy,  Larry  (Motorola,  Inc.) 

•  Nicol,  Mike  (U.S.  Air  Force  ASC/EN)22 

•  Peterson,  Bill  (Software  Engineering  Institute) 

•  Rassa,  Bob  (Raytheon  Space  &  Airborne  Systems)23 

•  Weszka,  Joan  (Lockheed  Martin) 

•  Wilson,  Hal  (Northrop  Grumman  Mission  Systems) 

•  Zettervall,  Brenda  (U.S.  Navy,  ASN/RDA  CHENG) 


22  Government  Co-Chair 

23  Industry  Co-Chair 
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D.  Glossary 


The  CMMI  glossary  defines  the  basic  terms  used  in  the  CMMI 
models.  Glossary  entries  are  typically  multiple-word  terms 
consisting  of  a  noun  and  one  or  more  restrictive  modifiers. 
(There  are  some  exceptions  to  this  rule  that  account  for  one- 
word  terms  in  the  glossary.) 

To  formulate  definitions  appropriate  for  CMMI,  we  consult 
multiple  sources.  We  first  consult  Merriam-Webster  OnLine 
dictionary  (www.m-w.com)  and  the  source  models  (i.e.,  EIA 
731,  SW-CMM  v2,  draft  C,  and  IPD-CMM  v0.98).  We  also 
consult  other  standards  as  needed,  including  the  following: 

•  ISO  9000  [ISO  1987] 

•  ISO/I  EC  12207  [ISO  1995] 

•  ISO/I  EC  15504  [ISO  2006] 

•  I  SO/I  EC  15288  [ISO  2002b] 

•  IEEE  [IEEE  1990] 

•  SW-CMM  vl.1 

•  EIA  632  [EIA  1994] 

•  SA-CMM  [SEI  2002c] 

•  P-CMM  [Curtis  2002] 

We  developed  the  glossary  recognizing  the  importance  of  using 
terminology  that  all  model  users  can  understand.  We  also 
recognized  that  words  and  terms  can  have  different  meanings 
in  different  contexts  and  environments.  The  glossary  in  CMMI 
models  is  designed  to  document  the  meanings  of  words  and 
terms  that  should  have  the  widest  use  and  understanding  by 
users  of  CMMI  products. 


acceptance  criteria  The  criteria  that  a  product  or  product  component  must 

satisfy  to  be  accepted  by  a  user,  customer,  or  other 
authorized  entity. 

acceptance  testing  Formal  testing  conducted  to  enable  a  user,  customer,  or 

other  authorized  entity  to  determine  whether  to  accept  a 
product  or  product  component.  (See  also  “unit  testing.”) 
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achievement  profile 

acquisition 
acquisition  strategy 

addition 

adequate 

allocated 

requirement 

alternative  practice 

amplification 

appraisal 


In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels  that  represent  the 
organization’s  progress  for  each  process  area  while 
advancing  through  the  capability  levels.  (See  also  “capability 
level  profile,”  “target  profile,”  and  “target  staging.”) 

The  process  of  obtaining  products  (goods  and  services) 
through  contract. 

The  specific  approach  to  acquiring  products  and  services 
that  is  based  on  considerations  of  supply  sources, 
acquisition  methods,  requirements  specification  types, 
contract  or  agreement  types,  and  the  related  acquisition  risk. 

In  the  CMMI  Product  Suite,  a  clearly  marked  model 
component  that  contains  information  of  interest  to  particular 
users.  In  a  CMMI  model,  all  additions  bearing  the  same 
name  (e.g.,  the  IPPD  addition)  may  be  optionally  selected 
as  a  group  for  use. 

This  word  is  used  so  that  you  can  interpret  goals  and 
practices  in  light  of  your  organization’s  business  objectives. 
When  using  any  CMMI  model,  you  must  interpret  the 
practices  so  that  they  work  for  your  organization.  This  term 
is  used  in  goals  and  practices  where  certain  activities  may 
not  be  done  all  of  the  time.  (See  also  “appropriate”  and  “as 
needed.”) 

Requirement  that  levies  all  or  part  of  the  performance  and 
functionality  of  a  higher  level  requirement  on  a  lower  level 
architectural  element  or  design  component. 

A  practice  that  is  a  substitute  for  one  or  more  generic  or 
specific  practices  contained  in  CMMI  models  that  achieves 
an  equivalent  effect  toward  satisfying  the  generic  or  specific 
goal  associated  with  model  practices.  Alternative  practices 
are  not  necessarily  one-for-one  replacements  for  the  generic 
or  specific  practices. 

Amplifications  are  informative  model  components  that 
contain  information  relevant  to  a  particular  discipline.  For 
example,  to  find  an  amplification  for  software  engineering, 
you  would  look  in  the  model  for  items  labeled  “For  Software 
Engineering.”  The  same  is  true  for  other  disciplines. 

In  the  CMMI  Product  Suite,  an  examination  of  one  or  more 
processes  by  a  trained  team  of  professionals  using  an 
appraisal  reference  model  as  the  basis  for  determining,  at  a 
minimum,  strengths  and  weaknesses.  (See  also 
“assessment”  and  “capability  evaluation.”) 
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appraisal  findings 

appraisal 

participants 

appraisal  rating 


appraisal  reference 
model 


appraisal  scope 


appropriate 


as  needed 


assessment 


assignable  cause  of 
process  variation 


The  results  of  an  appraisal  that  identify  the  most  important 
issues,  problems,  or  opportunities  for  process  improvement 
within  the  appraisal  scope.  Appraisal  findings  are  inferences 
drawn  from  corroborated  objective  evidence. 

Members  of  the  organizational  unit  who  participate  in 
providing  information  during  the  appraisal. 

As  used  in  CMMI  appraisal  materials,  the  value  assigned  by 
an  appraisal  team  to  (a)  a  CMMI  goal  or  process  area,  (b) 
the  capability  level  of  a  process  area,  or  (c)  the  maturity 
level  of  an  organizational  unit.  The  rating  is  determined  by 
enacting  the  defined  rating  process  for  the  appraisal  method 
being  employed. 

As  used  in  CMMI  appraisal  materials,  the  CMMI  model  to 
which  an  appraisal  team  correlates  implemented  process 
activities. 

The  definition  of  the  boundaries  of  the  appraisal 
encompassing  the  organizational  limits  and  the  CMMI  model 
limits  within  which  the  processes  to  be  investigated  operate. 

This  word  is  used  so  that  you  can  interpret  goals  and 
practices  in  light  of  your  organization’s  business  objectives. 
When  using  any  CMMI  model,  you  must  interpret  the 
practices  so  that  they  work  for  your  organization.  This  term 
is  used  in  goals  and  practices  where  certain  activities  may 
not  be  done  all  of  the  time.  (See  also  “adequate”  and  “as 
needed.”) 

This  phrase  is  used  so  that  you  can  interpret  goals  and 
practices  in  light  of  your  organization’s  business  objectives. 
When  using  any  CMMI  model,  you  must  interpret  the 
practices  so  that  they  work  for  your  organization.  This  term 
is  used  in  goals  and  practices  where  certain  activities  may 
not  be  done  all  the  time.  (See  also  “adequate”  and 
“appropriate.”) 

In  the  CMMI  Product  Suite,  an  appraisal  that  an  organization 
does  internally  for  the  purposes  of  process  improvement. 
The  word  assessment  is  also  used  in  the  CMMI  Product 
Suite  in  an  everyday  English  sense  (e.g.,  risk  assessment). 
(See  also  “appraisal”  and  “capability  evaluation.”) 

In  CMMI,  the  term  special  cause  of  process  variation  is  used 
in  place  of  assignable  cause  of  process  variation  to  ensure 
consistency.  The  two  terms  are  defined  identically.  (See 
“special  cause  of  process  variation.”) 
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audit 


base  measure 


baseline 


bidirectional 

traceability 


business  objectives 

capability 

evaluation 


capability  level 


capability  level 
profile 


capability  maturity 
model 


In  CMMI  process  improvement  work,  an  objective 
examination  of  a  work  product  or  set  of  work  products 
against  specific  criteria  (e.g.,  requirements). 

A  distinct  property  or  characteristic  of  an  entity  and  the 
method  for  quantifying  it.  (See  also  “derived  measures.”) 

A  set  of  specifications  or  work  products  that  has  been 
formally  reviewed  and  agreed  on,  which  thereafter  serves  as 
the  basis  for  further  development,  and  which  can  be 
changed  only  through  change  control  procedures.  (See  also 
“configuration  baseline”  and  “product  baseline.”) 

An  association  among  two  or  more  logical  entities  that  is 
discernable  in  either  direction  (i.e.,  to  and  from  an  entity). 
(See  also  “requirements  traceability”  and  “traceability.”) 

(See  “organization’s  business  objectives.”) 

An  appraisal  by  a  trained  team  of  professionals  used  as  a 
discriminator  to  select  suppliers,  to  monitor  suppliers  against 
the  contract,  or  to  determine  and  enforce  incentives. 
Evaluations  are  used  to  gain  insight  into  the  process 
capability  of  a  supplier  organization  and  are  intended  to  help 
decision  makers  make  better  acquisition  decisions,  improve 
subcontractor  performance,  and  provide  insight  to  a 
purchasing  organization.  (See  also  “appraisal”  and 
“assessment.”) 

Achievement  of  process  improvement  within  an  individual 
process  area.  A  capability  level  is  defined  by  the  appropriate 
specific  and  generic  practices  for  a  process  area.  (See  also 
“generic  goal,”  “generic  practice,”  “maturity  level,”  and 
“process  area.”) 

In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels.  (See  also 
“achievement  profile,”  “target  profile,”  and  “target  staging.”) 

The  profile  may  be  an  achievement  profile  when  it 
represents  the  organization’s  progress  for  each  process 
area  while  advancing  through  the  capability  levels.  Or,  the 
profile  may  be  a  target  profile  when  it  represents  an 
objective  for  process  improvement. 

A  model  that  contains  the  essential  elements  of  effective 
processes  for  one  or  more  disciplines  and  describes  an 
evolutionary  improvement  path  from  ad  hoc,  immature 
processes  to  disciplined,  mature  processes  with  improved 
quality  and  effectiveness. 


Glossary 


535 


CMMI  for  Development 
Version  1.2 


capable  process 


causal  analysis 

change 

management 


CMMI  Framework 


CMMI  model 


CMMI  model 
component 


A  process  that  can  satisfy  its  specified  product  quality, 
service  quality,  and  process-performance  objectives.  (See 
also  “stable  process,”  “standard  process,”  and  “statistically 
managed  process.”) 

The  analysis  of  defects  to  determine  their  cause. 

Judicious  use  of  means  to  effect  a  change,  or  a  proposed 
change,  on  a  product  or  service.  (See  also  “configuration 
management.”) 

The  basic  structure  that  organizes  CMMI  components, 
including  common  elements  of  the  current  CMMI  models  as 
well  as  rules  and  methods  for  generating  models,  appraisal 
methods  (including  associated  artifacts),  and  training 
materials.  The  framework  enables  new  disciplines  to  be 
added  to  CMMI  so  that  the  new  disciplines  will  integrate  with 
the  existing  ones.  (See  also  “CMMI  model”  and  “CMMI 
Product  Suite.”) 

One  from  the  entire  collection  of  possible  models  that  can 
be  generated  from  the  CMMI  Framework.  Since  the  CMMI 
Framework  can  generate  different  models  based  on  the 
needs  of  the  organization  using  it,  there  are  multiple  CMMI 
models.  (See  also  “CMMI  Framework”  and  “CMMI  Product 
Suite.”) 

Any  of  the  main  architectural  elements  that  compose  a 
CMMI  model.  Some  of  the  main  elements  of  a  CMMI  model 
include  specific  practices,  generic  practices,  specific  goals, 
generic  goals,  process  areas,  capability  levels,  and  maturity 
levels. 


CMMI  Product  Suite 


common  cause  of 
process  variation 


concept  of 
operations 


The  complete  set  of  products  developed  around  the  CMMI 
concept.  These  products  include  the  framework  itself, 
models,  appraisal  methods,  appraisal  materials,  and  various 
types  of  training.  (See  also  “CMMI  Framework”  and  “CMMI 
model.”) 

The  variation  of  a  process  that  exists  because  of  normal  and 
expected  interactions  among  the  components  of  a  process. 
(See  also  “special  cause  of  process  variation.”) 

(See  “operational  concept.”) 
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configuration  audit 


configuration 

baseline 


configuration 

control 


configuration 
control  board 


configuration 

identification 


configuration  item 


configuration 

management 


An  audit  conducted  to  verify  that  a  configuration  item,  or  a 
collection  of  configuration  items  that  make  up  a  baseline, 
conforms  to  a  specified  standard  or  requirement.  (See  also 
“audit,”  “configuration  item,”  “functional  configuration  audit,” 
and  “physical  configuration  audit.”) 

The  configuration  information  formally  designated  at  a 
specific  time  during  a  product’s  or  product  component’s  life. 
Configuration  baselines,  plus  approved  changes  from  those 
baselines,  constitute  the  current  configuration  information. 
(See  also  “product  lifecycle.”) 

An  element  of  configuration  management  consisting  of  the 
evaluation,  coordination,  approval  or  disapproval,  and 
implementation  of  changes  to  configuration  items  after 
formal  establishment  of  their  configuration  identification. 
(See  also  “configuration  identification,”  “configuration  item,” 
and  “configuration  management.”) 

A  group  of  people  responsible  for  evaluating  and  approving 
or  disapproving  proposed  changes  to  configuration  items, 
and  for  ensuring  implementation  of  approved  changes.  (See 
also  “configuration  item.”) 

Configuration  control  boards  are  also  known  as  change 
control  boards. 

An  element  of  configuration  management  consisting  of 
selecting  the  configuration  items  for  a  product,  assigning 
unique  identifiers  to  them,  and  recording  their  functional  and 
physical  characteristics  in  technical  documentation.  (See 
also  “configuration  item,”  “configuration  management,”  and 
“product.”) 

An  aggregation  of  work  products  that  is  designated  for 
configuration  management  and  treated  as  a  single  entity  in 
the  configuration  management  process.  (See  also 
“configuration  management.”) 

A  discipline  applying  technical  and  administrative  direction 
and  surveillance  to  (1)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item,  (2) 
control  changes  to  those  characteristics,  (3)  record  and 
report  change  processing  and  implementation  status,  and 
(4)  verify  compliance  with  specified  requirements.  (See  also 
“configuration  audit,”  “configuration  control,”  “configuration 
identification,”  and  “configuration  status  accounting.”) 
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configuration  status 
accounting 


continuous 

representation 


contractor 
corrective  action 


COTS 


customer 


customer 

requirement 


data 


data  management 


An  element  of  configuration  management  consisting  of  the 
recording  and  reporting  of  information  needed  to  manage  a 
configuration  effectively.  This  information  includes  a  listing 
of  the  approved  configuration  identification,  the  status  of 
proposed  changes  to  the  configuration,  and  the 
implementation  status  of  approved  changes.  (See  also 
“configuration  identification”  and  “configuration 
management.”) 

A  capability  maturity  model  structure  wherein  capability 
levels  provide  a  recommended  order  for  approaching 
process  improvement  within  each  specified  process  area. 
(See  also  “capability  level,”  “process  area,”  and  “staged 
representation.”) 

(See  “supplier.”) 

Acts  or  deeds  used  to  remedy  a  situation,  remove  an  error, 
or  adjust  a  condition. 

Items  that  can  be  purchased  from  a  commercial  vendor. 
(COTS  stands  for  commercial  off  the  shelf.) 

The  party  (individual,  project,  or  organization)  responsible 
for  accepting  the  product  or  for  authorizing  payment.  The 
customer  is  external  to  the  project  (except  possibly  when 
integrated  teams  are  used,  as  in  IPPD),  but  not  necessarily 
external  to  the  organization.  The  customer  may  be  a  higher 
level  project.  Customers  are  a  subset  of  stakeholders.  (See 
also  “stakeholder.”) 

In  most  cases  where  this  term  is  used,  the  preceding  definition  is 
intended;  however,  in  some  contexts,  the  term  “customer”  is  intended  to 
include  other  relevant  stakeholders.  (See  also  “customer  requirement.”) 

The  result  of  eliciting,  consolidating,  and  resolving  conflicts 
among  the  needs,  expectations,  constraints,  and  interfaces 
of  the  product's  relevant  stakeholders  in  a  way  that  is 
acceptable  to  the  customer.  (See  also  “customer.”) 

Recorded  information,  regardless  of  the  form  or  method  of 
recording,  including  technical  data,  computer  software 
documents,  financial  information,  management  information, 
representation  of  facts,  numbers,  or  datum  of  any  nature 
that  can  be  communicated,  stored,  and  processed. 

The  disciplined  processes  and  systems  that  plan  for, 
acquire,  and  provide  stewardship  for  business  and  technical 
data,  consistent  with  data  requirements,  throughout  the  data 
lifecycle. 
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defect  density 
defined  process 


derived  measures 


derived 

requirements 


design  review 


development 


developmental  plan 


discipline 


document 


enterprise 


Number  of  defects  per  unit  of  product  size  (e.g.,  problem 
reports  per  thousand  lines  of  code). 

A  managed  process  that  is  tailored  from  the  organization’s 
set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description; 
and  contributes  work  products,  measures,  and  other 
process  improvement  information  to  the  organizational 
process  assets.  (See  also  “managed  process.”) 

Data  resulting  from  the  mathematical  function  of  two  or  more 
base  measures.  (See  also  “base  measure.”) 

Requirements  that  are  not  explicitly  stated  in  the  customer 
requirements,  but  are  inferred  (1)  from  contextual 
requirements  (e.g.,  applicable  standards,  laws,  policies, 
common  practices,  and  management  decisions),  or  (2)  from 
requirements  needed  to  specify  a  product  component. 
Derived  requirements  can  also  arise  during  analysis  and 
design  of  components  of  the  product  or  system.  (See  also 
“product  requirements.”) 

A  formal,  documented,  comprehensive,  and  systematic 
examination  of  a  design  to  evaluate  the  design  requirements 
and  the  capability  of  the  design  to  meet  these  requirements, 
and  to  identify  problems  and  propose  solutions. 

In  the  CMMI  Product  Suite,  not  only  development  activities 
but  also  maintenance  activities  may  be  included.  Projects 
that  benefit  from  the  best  practices  of  CMMI  can  focus  on 
development,  maintenance,  or  both. 

A  plan  for  guiding,  implementing,  and  controlling  the  design 
and  development  of  one  or  more  products.  (See  also 
“product  lifecycle”  and  “project  plan.”) 

In  the  CMMI  Product  Suite,  the  bodies  of  knowledge 
available  to  you  when  selecting  a  CMMI  model  (e.g., 
systems  engineering).  The  CMMI  Product  Team  envisions 
that  other  bodies  of  knowledge  will  be  integrated  into  the 
CMMI  Framework  in  the  future. 

A  collection  of  data,  regardless  of  the  medium  on  which  it  is 
recorded,  that  generally  has  permanence  and  can  be  read 
by  humans  or  machines.  So,  documents  include  both  paper 
and  electronic  documents. 

The  full  composition  of  companies.  Companies  may  consist 
of  many  organizations  in  many  locations  with  different 
customers.  (See  also  “organization.”) 
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entry  criteria 
equivalent  staging 


establish  and 
maintain 


evidence 
executive 
exit  criteria 

expected  CMMI 
components 

finding 

formal  evaluation 
process 

framework 


States  of  being  that  must  be  present  before  an  effort  can 
begin  successfully. 

A  target  staging,  created  using  the  continuous 
representation,  which  is  defined  so  that  the  results  of  using 
the  target  staging  can  be  compared  to  the  maturity  levels  of 
the  staged  representation.  (See  also  “capability  level 
profile,”  “maturity  level,”  “target  profile,”  and  “target  staging.”) 

Such  staging  permits  benchmarking  of  progress  among 
organizations,  enterprises,  and  projects,  regardless  of  the 
CMMI  representation  used.  The  organization  may 
implement  components  of  CMMI  models  beyond  those 
reported  as  part  of  equivalent  staging.  Equivalent  staging  is 
only  a  measure  to  relate  how  the  organization  is  compared 
to  other  organizations  in  terms  of  maturity  levels. 

In  the  CMMI  Product  Suite,  you  will  encounter  goals  and 
practices  that  include  the  phrase  “establish  and  maintain.” 
This  phrase  means  more  than  a  combination  of  its 
component  terms;  it  includes  documentation  and  usage.  For 
example,  “Establish  and  maintain  an  organizational  policy 
for  planning  and  performing  the  organizational  process 
focus  process”  means  that  not  only  must  a  policy  be 
formulated,  but  it  also  must  be  documented,  and  it  must  be 
used  throughout  the  organization. 

(See  “objective  evidence.”) 

(See  “senior  manager.”) 

States  of  being  that  must  be  present  before  an  effort  can 
end  successfully. 

CMMI  components  that  explain  what  may  be  done  to  satisfy 
a  required  CMMI  component.  Model  users  can  implement 
the  expected  components  explicitly  or  implement  equivalent 
alternative  practices  to  these  components.  Specific  and 
generic  practices  are  expected  model  components. 

(See  “appraisal  findings.”) 

A  structured  approach  to  evaluating  alternative  solutions 
against  established  criteria  to  determine  a  recommended 
solution  to  address  an  issue. 

(See  “CMMI  Framework.”) 
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functional  analysis 


functional 

architecture 


functional 
configuration  audit 


generic  goal 


generic  practice 

generic  practice 
elaboration 

goal 


Examination  of  a  defined  function  to  identify  all  the 
subfunctions  necessary  to  the  accomplishment  of  that 
function;  identification  of  functional  relationships  and 
interfaces  (internal  and  external)  and  capturing  these  in  a 
functional  architecture;  and  flow  down  of  upper  level 
performance  requirements  and  assignment  of  these 
requirements  to  lower  level  subfunctions.  (See  also 
“functional  architecture.”) 

The  hierarchical  arrangement  of  functions,  their  internal  and 
external  (external  to  the  aggregation  itself)  functional 
interfaces  and  external  physical  interfaces,  their  respective 
functional  and  performance  requirements,  and  their  design 
constraints. 

An  audit  conducted  to  verify  that  the  development  of  a 
configuration  item  has  been  completed  satisfactorily,  that 
the  item  has  achieved  the  performance  and  functional 
characteristics  specified  in  the  functional  or  allocated 
configuration  identification,  and  that  its  operational  and 
support  documents  are  complete  and  satisfactory.  (See  also 
“configuration  audit,”  “configuration  management,”  and 
“physical  configuration  audit.”) 

A  required  model  component  that  describes  the 
characteristics  that  must  be  present  to  institutionalize  the 
processes  that  implement  a  process  area.  (See  also 
“institutionalization.”) 

An  expected  model  component  that  is  considered  important 
in  achieving  the  associated  generic  goal.  The  generic 
practices  associated  with  a  generic  goal  describe  the 
activities  that  are  expected  to  result  in  achievement  of  the 
generic  goal  and  contribute  to  the  institutionalization  of  the 
processes  associated  with  a  process  area. 

An  informative  model  component  that  appears  after  a 
generic  practice  to  provide  guidance  on  how  the  generic 
practice  should  be  applied  to  the  process  area. 

A  required  CMMI  component  that  can  be  either  a  generic 
goal  or  a  specific  goal.  When  you  see  the  word  goal  in  a 
CMMI  model,  it  always  refers  to  a  model  component  (e.g., 
generic  goal  and  specific  goal).  (See  also  “generic  goal,” 
“objective,”  and  “specific  goal.”) 
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hardware 

engineering 


higher  level 
management 


incomplete  process 


informative  CMMI 
components 


institutionalization 


integrated  product 
and  process 
development 


integrated  team 


The  application  of  a  systematic,  disciplined,  and  quantifiable 
approach  to  transform  a  set  of  requirements  representing 
the  collection  of  stakeholder  needs,  expectations,  and 
constraints  using  documented  techniques  and  technology  to 
design,  implement,  and  maintain  a  tangible  product.  (See 
also  “software  engineering”  and  “systems  engineering.”) 

In  CMMI,  hardware  engineering  represents  all  technical  fields  (e.g., 
electrical  or  mechanical)  that  transform  requirements  and  ideas  into 
tangible  and  producible  products. 

The  person  or  persons  who  provide  the  policy  and  overall 
guidance  for  the  process,  but  do  not  provide  the  direct  day- 
to-day  monitoring  and  controlling  of  the  process.  Such 
persons  belong  to  a  level  of  management  in  the  organization 
above  the  immediate  level  responsible  for  the  process  and 
can  be  (but  are  not  necessarily)  senior  managers.  (See  also 
“senior  manager.”) 

A  process  that  is  not  performed  or  is  performed  only  partially 
(also  known  as  capability  level  0).  One  or  more  of  the 
specific  goals  of  the  process  area  are  not  satisfied. 

CMMI  components  that  help  model  users  understand  the 
required  and  expected  components  of  a  model.  These 
components  can  contain  examples,  detailed  explanations,  or 
other  helpful  information.  Subpractices,  notes,  references, 
goal  titles,  practice  titles,  sources,  typical  work  products, 
amplifications,  and  generic  practice  elaborations  are 
informative  model  components. 

The  ingrained  way  of  doing  business  that  an  organization 
follows  routinely  as  part  of  its  corporate  culture. 

A  systematic  approach  to  product  development  that 
achieves  a  timely  collaboration  of  relevant  stakeholders 
throughout  the  product  lifecycle  to  better  satisfy  customer 
needs. 

A  group  of  people  with  complementary  skills  and  expertise 
who  are  committed  to  delivering  specified  work  products  in 
timely  collaboration.  Integrated  team  members  provide  skills 
and  advocacy  appropriate  to  all  phases  of  the  work 
products’  life  and  are  collectively  responsible  for  delivering 
the  work  products  as  specified.  An  integrated  team  should 
include  empowered  representatives  from  organizations, 
disciplines,  and  functions  that  have  a  stake  in  the  success  of 
the  work  products. 


542 


Glossary 


CMMI  for  Development 
Version  1.2 


interface  control 


lifecycle  model 
managed  process 


manager 


maturity  level 


memorandum  of 
agreement 


natural  bounds 


nondevelopmental 
item  (NDI) 


In  configuration  management,  the  process  of  (1)  identifying 
all  functional  and  physical  characteristics  relevant  to  the 
interfacing  of  two  or  more  configuration  items  provided  by 
one  or  more  organizations,  and  (2)  ensuring  that  the 
proposed  changes  to  these  characteristics  are  evaluated 
and  approved  prior  to  implementation.  (See  also 
“configuration  item”  and  “configuration  management.”) 

A  partitioning  of  the  life  of  a  product  or  project  into  phases. 

A  performed  process  that  is  planned  and  executed  in 
accordance  with  policy;  employs  skilled  people  having 
adequate  resources  to  produce  controlled  outputs;  involves 
relevant  stakeholders;  is  monitored,  controlled,  and 
reviewed;  and  is  evaluated  for  adherence  to  its  process 
description.  (See  also  “performed  process.”) 

In  the  CMMI  Product  Suite,  a  person  who  provides  technical 
and  administrative  direction  and  control  to  those  performing 
tasks  or  activities  within  the  manager’s  area  of  responsibility. 
The  traditional  functions  of  a  manager  include  planning, 
organizing,  directing,  and  controlling  work  within  an  area  of 
responsibility. 

Degree  of  process  improvement  across  a  predefined  set  of 
process  areas  in  which  all  goals  in  the  set  are  attained.  (See 
also  “capability  level”  and  “process  area.”) 

Binding  documents  of  understanding  or  agreements 
between  two  or  more  parties.  Also  known  as  a 
“memorandum  of  understanding.” 

The  inherent  process  reflected  by  measures  of  process 
performance,  sometimes  referred  to  as  “voice  of  the 
process.”  Techniques  such  as  control  charts,  confidence 
intervals,  and  prediction  intervals  are  used  to  determine 
whether  the  variation  is  due  to  common  causes  (i.e.,  the 
process  is  predictable  or  “stable”)  or  is  due  to  some  special 
cause  that  can  and  should  be  identified  and  removed. 

An  item  of  supply  that  was  developed  prior  to  its  current  use 
in  an  acquisition  or  development  process.  Such  an  item  may 
require  minor  modifications  to  meet  the  requirements  of  its 
current  intended  use. 
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nontechnical 

requirements 


objective 


objective  evidence 


objectively  evaluate 


observation 


operational  concept 


operational 

scenario 


Contractual  provisions,  commitments,  conditions,  and  terms 
that  affect  how  products  or  services  are  to  be  acquired. 
Examples  include  products  to  be  delivered,  data  rights  for 
delivered  commercial  off-the-shelf  (COTS) 
nondevelopmental  items  (NDIs),  delivery  dates,  and 
milestones  with  exit  criteria.  Other  nontechnical 
requirements  include  training  requirements,  site 
requirements,  and  deployment  schedules. 

When  used  as  a  noun  in  the  CMMI  Product  Suite,  the  term 
objective  replaces  the  word  goal  as  used  in  its  common 
everyday  sense  since  the  word  goal  is  reserved  for  use 
when  referring  to  the  CMMI  model  components  called 
specific  goals  and  generic  goals.  (See  also  “goal.”) 

As  used  in  CMMI  appraisal  materials,  documents  or 
interview  results  used  as  indicators  of  the  implementation  or 
institutionalization  of  model  practices.  Sources  of  objective 
evidence  can  include  instruments,  presentations, 
documents,  and  interviews. 

To  review  activities  and  work  products  against  criteria  which 
minimize  subjectivity  and  bias  by  the  reviewer.  An  example 
of  an  objective  evaluation  is  an  audit  against  requirements, 
standards,  or  procedures  by  an  independent  quality 
assurance  function.  (See  also  “audit.”) 

As  used  in  CMMI  appraisal  materials,  a  written  record  that 
represents  the  appraisal  team  members’  understanding  of 
information  either  seen  or  heard  during  the  appraisal  data 
collection  activities.  The  written  record  may  take  the  form  of 
a  statement  or  may  take  alternative  forms  as  long  as  the 
information  content  is  preserved. 

A  general  description  of  the  way  in  which  an  entity  is  used  or 
operates.  (Also  known  as  “concept  of  operations.”) 

A  description  of  an  imagined  sequence  of  events  that 
includes  the  interaction  of  the  product  with  its  environment 
and  users,  as  well  as  interaction  among  its  product 
components.  Operational  scenarios  are  used  to  evaluate  the 
requirements  and  design  of  the  system  and  to  verify  and 
validate  the  system. 
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optimizing  process 


organization 


organizational 

maturity 


organizational 

policy 


organizational 
process  assets 


organizational  unit 


A  quantitatively  managed  process  that  is  improved  based  on 
an  understanding  of  the  common  causes  of  variation 
inherent  in  the  process.  The  focus  of  an  optimizing  process 
is  on  continually  improving  the  range  of  process 
performance  through  both  incremental  and  innovative 
improvements.  (See  also  “common  cause  of  process 
variation,”  “defined  process,”  and  “quantitatively  managed 
process.”) 

An  administrative  structure  in  which  people  collectively 
manage  one  or  more  projects  as  a  whole,  and  whose 
projects  share  a  senior  manager  and  operate  under  the 
same  policies.  However,  the  word  organization  as  used 
throughout  CMMI  models  can  also  apply  to  one  person  who 
performs  a  function  in  a  small  organization  that  might  be 
performed  by  a  group  of  people  in  a  large  organization.  (See 
also  “enterprise”  and  “organizational  unit.”) 

The  extent  to  which  an  organization  has  explicitly  and 
consistently  deployed  processes  that  are  documented, 
managed,  measured,  controlled,  and  continually  improved. 
Organizational  maturity  may  be  measured  via  appraisals. 

A  guiding  principle  typically  established  by  senior 
management  that  is  adopted  by  an  organization  to  influence 
and  determine  decisions. 

Artifacts  that  relate  to  describing,  implementing,  and 
improving  processes  (e.g.,  policies,  measurements,  process 
descriptions,  and  process  implementation  support  tools). 

The  term  process  assets  is  used  to  indicate  that  these 
artifacts  are  developed  or  acquired  to  meet  the  business 
objectives  of  the  organization,  and  they  represent 
investments  by  the  organization  that  are  expected  to  provide 
current  and  future  business  value.  (See  also  “process  asset 
library.”) 

The  part  of  an  organization  that  is  the  subject  of  an 
appraisal.  An  organizational  unit  deploys  one  or  more 
processes  that  have  a  coherent  process  context  and 
operates  within  a  coherent  set  of  business  objectives.  An 
organizational  unit  is  typically  part  of  a  larger  organization, 
although  in  a  small  organization,  the  organizational  unit  may 
be  the  whole  organization. 
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organization's 
business  objectives 


organization's 

measurement 

repository 


organization's 
process  asset 
library 


organization's  set  of 
standard  processes 


outsourcing 
peer  review 


performance 

parameters 


Senior  management  developed  strategies  designed  to 
ensure  an  organization’s  continued  existence  and  enhance 
its  profitability,  market  share,  and  other  factors  influencing 
the  organization’s  success.  (See  also  “quality  and  process- 
performance  objectives”  and  “quantitative  objective.”) 

Such  objectives  may  include  reducing  the  number  of  change 
requests  during  a  system’s  integration  phase,  reducing 
development  cycle  time,  increasing  the  number  of  errors 
found  in  a  product’s  first  or  second  phase  of  development, 
and  reducing  the  number  of  customer-reported  defects, 
when  applied  to  systems  engineering  activities. 

A  repository  used  to  collect  and  make  available 
measurement  data  on  processes  and  work  products, 
particularly  as  they  relate  to  the  organization’s  set  of 
standard  processes.  This  repository  contains  or  references 
actual  measurement  data  and  related  information  needed  to 
understand  and  analyze  the  measurement  data. 

A  library  of  information  used  to  store  and  make  available 
process  assets  that  are  useful  to  those  who  are  defining, 
implementing,  and  managing  processes  in  the  organization. 
This  library  contains  process  assets  that  include  process- 
related  documentation  such  as  policies,  defined  processes, 
checklists,  lessons-learned  documents,  templates, 
standards,  procedures,  plans,  and  training  materials. 

A  collection  of  definitions  of  the  processes  that  guide 
activities  in  an  organization.  These  process  descriptions 
cover  the  fundamental  process  elements  (and  their 
relationships  to  each  other,  such  as  ordering  and  interfaces) 
that  must  be  incorporated  into  the  defined  processes  that 
are  implemented  in  projects  across  the  organization.  A 
standard  process  enables  consistent  development  and 
maintenance  activities  across  the  organization  and  is 
essential  for  long-term  stability  and  improvement.  (See  also 
“defined  process”  and  “process  element.”) 

(See  “acquisition.”) 

The  review  of  work  products  performed  by  peers  during 
development  of  the  work  products  to  identify  defects  for 
removal.  The  term  peer  review  is  used  in  the  CMMI  Product 
Suite  instead  of  the  term  work  product  inspection.  (See  also 
“work  product.”) 

The  measures  of  effectiveness  and  other  key  measures 
used  to  guide  and  control  progressive  development. 
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performed  process 


physical 

configuration  audit 


planned  process 


policy 

process 


process  action  plan 


process  action  team 


process  and 

technology 

improvements 

process 

architecture 


A  process  that  accomplishes  the  needed  work  to  produce 
work  products.  The  specific  goals  of  the  process  area  are 
satisfied. 

An  audit  conducted  to  verify  that  a  configuration  item,  as 
built,  conforms  to  the  technical  documentation  that  defines 
and  describes  it.  (See  also,  “configuration  audit,” 
“configuration  management,”  and  “functional  configuration 
audit.”) 

A  process  that  is  documented  by  both  a  description  and  a 
plan.  The  description  and  plan  should  be  coordinated,  and 
the  plan  should  include  standards,  requirements,  objectives, 
resources,  assignments,  and  so  on. 

(See  “organizational  policy.”) 

In  the  CMMI  Product  Suite,  activities  that  can  be  recognized 
as  implementations  of  practices  in  a  CMMI  model.  These 
activities  can  be  mapped  to  one  or  more  practices  in  CMMI 
process  areas  to  allow  a  model  to  be  useful  for  process 
improvement  and  process  appraisal.  (See  also  “process 
area,”  “subprocess,”  and  “process  element.”) 

There  is  a  special  use  of  the  phrase  “the  process”  in  the 
statements  and  descriptions  of  the  generic  goals  and 
generic  practices.  “The  process,”  as  used  in  Part  Two,  is  the 
process  or  processes  that  implement  the  process  area. 

A  plan,  usually  resulting  from  appraisals,  that  documents 
how  specific  improvements  targeting  the  weaknesses 
uncovered  by  an  appraisal  will  be  implemented. 

A  team  that  has  the  responsibility  to  develop  and  implement 
process  improvement  activities  for  an  organization  as 
documented  in  a  process  action  plan. 

Incremental  and  innovative  improvements  to  processes  and 
to  process  or  product  technologies. 

The  ordering,  interfaces,  interdependencies,  and  other 
relationships  among  the  process  elements  in  a  standard 
process.  Process  architecture  also  describes  the  interfaces, 
interdependencies,  and  other  relationships  between  process 
elements  and  external  processes  (e.g.,  contract 
management). 
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process  group 
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A  cluster  of  related  practices  in  an  area  that,  when 
implemented  collectively,  satisfy  a  set  of  goals  considered 
important  for  making  improvement  in  that  area.  All  CMMI 
process  areas  are  common  to  both  continuous  and  staged 
representations. 

Anything  that  the  organization  considers  useful  in  attaining 
the  goals  of  a  process  area.  (See  also  “organizational 
process  assets.”) 

A  collection  of  process  asset  holdings  that  can  be  used  by 
an  organization  or  project.  (See  also  “organization’s  process 
asset  library.”) 

A  measurable  characteristic  of  process  capability  applicable 
to  any  process. 

The  range  of  expected  results  that  can  be  achieved  by 
following  a  process. 

The  act  of  defining  and  describing  a  process.  The  result  of  a 
process  definition  is  a  process  description.  (See  also 
“process  description.”) 

A  documented  expression  of  a  set  of  activities  performed  to 
achieve  a  given  purpose. 

A  process  description  provides  an  operational  definition  of  the  major 
components  of  a  process.  The  description  specifies,  in  a  complete, 
precise,  and  verifiable  manner,  the  requirements,  design,  behavior,  or 
other  characteristics  of  a  process.  It  also  may  include  procedures  for 
determining  whether  these  provisions  have  been  satisfied.  Process 
descriptions  can  be  found  at  the  activity,  project,  or  organizational  level. 

The  fundamental  unit  of  a  process.  A  process  can  be 
defined  in  terms  of  subprocesses  or  process  elements.  A 
subprocess  can  be  further  decomposed  into  subprocesses 
or  process  elements;  a  process  element  cannot.  (See  also 
“process”  and  “subprocess.”) 

Each  process  element  covers  a  closely  related  set  of 
activities  (e.g.,  estimating  element  and  peer  review 
element).  Process  elements  can  be  portrayed  using 
templates  to  be  completed,  abstractions  to  be  refined,  or 
descriptions  to  be  modified  or  used.  A  process  element  can 
be  an  activity  or  task. 

A  collection  of  specialists  who  facilitate  the  definition, 
maintenance,  and  improvement  of  the  processes  used  by 
the  organization. 
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improvement 


process 

improvement 
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process 

improvement  plan 


process 

measurement 


process  owner 


process 

performance 


process- 

performance 

baseline 


process- 

performance  model 


A  program  of  activities  designed  to  improve  the  performance 
and  maturity  of  the  organization’s  processes  and  the  results 
of  such  a  program. 

A  set  of  target  characteristics  established  to  guide  the  effort 
to  improve  an  existing  process  in  a  specific,  measurable 
way  either  in  terms  of  resultant  product  characteristics  (e.g., 
quality,  performance,  and  conformance  to  standards)  or  in 
the  way  in  which  the  process  is  executed  (e.g.,  elimination 
of  redundant  process  steps,  combination  of  process  steps, 
and  improvement  of  cycle  time).  (See  also  “organization’s 
business  objectives”  and  “quantitative  objective.”) 

A  plan  for  achieving  organizational  process  improvement 
objectives  based  on  a  thorough  understanding  of  the  current 
strengths  and  weaknesses  of  the  organization’s  processes 
and  process  assets. 

The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for 
the  purpose  of  characterizing  and  understanding  the 
process. 

The  person  (or  team)  responsible  for  defining  and 
maintaining  a  process.  At  the  organizational  level,  the 
process  owner  is  the  person  (or  team)  responsible  for  the 
description  of  a  standard  process;  at  the  project  level,  the 
process  owner  is  the  person  (or  team)  responsible  for  the 
description  of  the  defined  process.  A  process  may  therefore 
have  multiple  owners  at  different  levels  of  responsibility. 

(See  also  “defined  process”  and  “standard  process.”) 

A  measure  of  actual  results  achieved  by  following  a  process. 
It  is  characterized  by  both  process  measures  (e.g.,  effort, 
cycle  time,  and  defect  removal  efficiency)  and  product 
measures  (e.g.,  reliability,  defect  density,  and  response 
time). 

A  documented  characterization  of  the  actual  results 
achieved  by  following  a  process,  which  is  used  as  a 
benchmark  for  comparing  actual  process  performance 
against  expected  process  performance.  (See  also  “process 
performance.”) 

A  description  of  the  relationships  among  attributes  of  a 
process  and  its  work  products  that  is  developed  from 
historical  process-performance  data  and  calibrated  using 
collected  process  and  product  measures  from  the  project 
and  that  is  used  to  predict  results  to  be  achieved  by 
following  a  process. 
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process  tailoring 


product 

product  baseline 


product  component 

product  component 
requirements 

product  lifecycle 


product  line 

product-related 
lifecycle  processes 


Making,  altering,  or  adapting  a  process  description  for  a 
particular  end.  For  example,  a  project  tailors  its  defined 
process  from  the  organization’s  set  of  standard  processes  to 
meet  the  objectives,  constraints,  and  environment  of  the 
project.  (See  also  “defined  process,”  “organization’s  set  of 
standard  processes,”  and  “process  description.”) 

In  the  CMMI  Product  Suite,  a  work  product  that  is  intended 
for  delivery  to  a  customer  or  end  user.  The  form  of  a  product 
can  vary  in  different  contexts.  (See  also  “customer,”  “product 
component,”  “service,”  and  “work  product.”) 

In  configuration  management,  the  initial  approved  technical 
data  package  (including,  for  software,  the  source  code 
listing)  defining  a  configuration  item  during  the  production, 
operation,  maintenance,  and  logistic  support  of  its  lifecycle. 
(See  also  “configuration  item”  and  “configuration 
management.”) 

In  the  CMMI  Product  Suite,  a  work  product  that  is  a  lower 
level  component  of  the  product.  Product  components  are 
integrated  to  produce  the  product.  There  may  be  multiple 
levels  of  product  components.  (See  also  “product”  and  “work 
product.”) 

A  complete  specification  of  a  product  component,  including 
fit,  form,  function,  performance,  and  any  other  requirement. 

The  period  of  time,  consisting  of  phases,  which  begins  when 
a  product  is  conceived  and  ends  when  the  product  is  no 
longer  available  for  use.  Since  an  organization  may  be 
producing  multiple  products  for  multiple  customers,  one 
description  of  a  product  lifecycle  may  not  be  adequate. 
Therefore,  the  organization  may  define  a  set  of  approved 
product  lifecycle  models.  These  models  are  typically  found 
in  published  literature  and  are  likely  to  be  tailored  for  use  in 
an  organization. 

A  product  lifecycle  could  consist  of  the  following  phases:  (1) 
concept/vision,  (2)  feasibility,  (3)  design/development,  (4) 
production,  and  (5)  phase  out. 

A  group  of  products  sharing  a  common,  managed  set  of 
features  that  satisfy  specific  needs  of  a  selected  market  or 
mission. 

Processes  associated  with  a  product  throughout  one  or 
more  phases  of  its  life  (e.g.,  from  conception  through 
disposal),  such  as  the  manufacturing  and  support 
processes. 
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product 

requirements 


product  suite 

profile 

program 


project 


project  manager 


project  plan 


project  progress 
and  performance 


project  startup 


A  refinement  of  the  customer  requirements  into  the 
developers’  language,  making  implicit  requirements  into 
explicit  derived  requirements.  (See  also  “derived 
requirements”  and  “product  component  requirements.”) 

The  developer  uses  the  product  requirements  to  guide  the 
design  and  building  of  the  product. 

(See  “CMMI  Product  Suite.”) 

(See  “achievement  profile”  and  “target  profile.”) 

(1 )  A  project.  (2)  A  collection  of  related  projects  and  the 
infrastructure  that  supports  them,  including  objectives, 
methods,  activities,  plans,  and  success  measures.  (See  also 
“project.”) 

In  the  CMMI  Product  Suite,  a  managed  set  of  interrelated 
resources  which  delivers  one  or  more  products  to  a 
customer  or  end  user.  A  project  has  a  definite  beginning 
(i.e. ,  project  startup)  and  typically  operates  according  to  a 
plan.  Such  a  plan  is  frequently  documented  and  specifies 
what  is  to  be  delivered  or  implemented,  the  resources  and 
funds  to  be  used,  the  work  to  be  done,  and  a  schedule  for 
doing  the  work.  A  project  can  be  composed  of  projects.  (See 
also  “project  startup.”) 

In  the  CMMI  Product  Suite,  the  person  responsible  for 
planning,  directing,  controlling,  structuring,  and  motivating 
the  project.  The  project  manager  is  responsible  for  satisfying 
the  customer. 

A  plan  that  provides  the  basis  for  performing  and  controlling 
the  project’s  activities,  which  addresses  the  commitments  to 
the  project’s  customer. 

Project  planning  includes  estimating  the  attributes  of  the 
work  products  and  tasks,  determining  the  resources  needed, 
negotiating  commitments,  producing  a  schedule,  and 
identifying  and  analyzing  project  risks.  Iterating  through 
these  activities  may  be  necessary  to  establish  the  project 
plan. 

What  a  project  achieves  with  respect  to  implementing 
project  plans,  including  effort,  cost,  schedule,  and  technical 
performance. 

When  a  set  of  interrelated  resources  are  directed  to  develop 
or  deliver  one  or  more  products  for  a  customer  or  end  user. 
(See  also  “project.”) 
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project's  defined 
process 


prototype 


quality 


quality  and  process- 

performance 

objectives 


quality  assurance 


quality  control 


quantitative 

objective 


The  integrated  and  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes.  (See  also  “defined 
process.”) 

A  preliminary  type,  form,  or  instance  of  a  product  or  product 
component  that  serves  as  a  model  for  later  stages  or  for  the 
final,  complete  version  of  the  product.  This  model  (e.g., 
physical,  electronic,  digital,  and  analytical)  can  be  used  for 
the  following  (and  other)  purposes: 

•  Assessing  the  feasibility  of  a  new  or  unfamiliar 
technology 

•  Assessing  or  mitigating  technical  risk 

•  Validating  requirements 

•  Demonstrating  critical  features 

•  Qualifying  a  product 

•  Qualifying  a  process 

•  Characterizing  performance  or  product  features 

•  Elucidating  physical  principles 

The  ability  of  a  set  of  inherent  characteristics  of  a  product, 
product  component,  or  process  to  fulfill  requirements  of 
customers. 

Objectives  and  requirements  for  product  quality,  service 
quality,  and  process  performance.  Process-performance 
objectives  include  quality;  however,  to  emphasize  the 
importance  of  quality  in  the  CMMI  Product  Suite,  the  phrase 
quality  and  process-performance  objectives  is  used  rather 
than  just  process-performance  objectives. 

A  planned  and  systematic  means  for  assuring  management 
that  the  defined  standards,  practices,  procedures,  and 
methods  of  the  process  are  applied. 

The  operational  techniques  and  activities  that  are  used  to 
fulfill  requirements  for  quality.  (See  also  “quality 
assurance.”) 

Desired  target  value  expressed  as  quantitative  measures. 
(See  also  “process  improvement  objectives”  and  “quality 
and  process-performance  objectives.”) 
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quantitatively 
managed  process 

rating 

reference 

reference  model 

relevant  stakeholder 

representation 

required  CMMI 
components 


requirement 


requirements 

analysis 


requirements 

elicitation 


requirements 

management 


A  defined  process  that  is  controlled  using  statistical  and 
other  quantitative  techniques.  The  product  quality,  service 
quality,  and  process-performance  attributes  are  measurable 
and  controlled  throughout  the  project.  (See  also  “defined 
process,”  “optimizing  process,”  and  “statistically  managed 
process.”) 

(See  “appraisal  rating.”) 

An  informative  model  component  that  points  to  additional  or 
more  detailed  information  in  related  process  areas. 

A  model  that  is  used  as  a  benchmark  for  measuring  some 
attribute. 

A  stakeholder  that  is  identified  for  involvement  in  specified 
activities  and  is  included  in  a  plan.  (See  also  “stakeholder.”) 

The  organization,  use,  and  presentation  of  a  CMM’s 
components.  Overall,  two  types  of  approaches  to  presenting 
best  practices  are  evident:  the  staged  representation  and 
the  continuous  representation. 

CMMI  components  that  are  essential  to  achieving  process 
improvement  in  a  given  process  area.  These  components 
are  used  in  appraisals  to  determine  process  capability. 
Specific  goals  and  generic  goals  are  required  model 
components. 

(1 )  A  condition  or  capability  needed  by  a  user  to  solve  a 
problem  or  achieve  an  objective.  (2)  A  condition  or  capability 
that  must  be  met  or  possessed  by  a  product  or  product 
component  to  satisfy  a  contract,  standard,  specification,  or 
other  formally  imposed  documents.  (3)  A  documented 
representation  of  a  condition  or  capability  as  in  (1 )  or  (2). 

The  determination  of  product-specific  performance  and 
functional  characteristics  based  on  analyses  of  customer 
needs,  expectations,  and  constraints;  operational  concept; 
projected  utilization  environments  for  people,  products,  and 
processes;  and  measures  of  effectiveness. 

Using  systematic  techniques,  such  as  prototypes  and 
structured  surveys,  to  proactively  identify  and  document 
customer  and  end-user  needs. 

The  management  of  all  requirements  received  by  or 
generated  by  the  project,  including  both  technical  and 
nontechnical  requirements  as  well  as  those  requirements 
levied  on  the  project  by  the  organization. 
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requirements 

traceability 

return  on 
investment 

risk  analysis 
risk  identification 

risk  management 


risk  management 
strategy 


root  cause 


senior  manager 


service 


A  discernable  association  between  requirements  and  related 
requirements,  implementations,  and  verifications.  (See  also 
“bidirectional  traceability”  and  “traceability.”) 

The  ratio  of  revenue  from  output  (product)  to  production 
costs,  which  determines  whether  an  organization  benefits 
from  performing  an  action  to  produce  something. 

The  evaluation,  classification,  and  prioritization  of  risks. 

An  organized,  thorough  approach  to  seek  out  probable  or 
realistic  risks  in  achieving  objectives. 

An  organized,  analytic  process  to  identify  what  might  cause 
harm  or  loss  (identify  risks);  to  assess  and  quantify  the 
identified  risks;  and  to  develop  and,  if  needed,  implement  an 
appropriate  approach  to  prevent  or  handle  causes  of  risk 
that  could  result  in  significant  harm  or  loss. 

An  organized,  technical  approach  to  identify  what  might 
cause  harm  or  loss  (identify  risks);  to  assess  and  quantify 
the  identified  risks;  and  to  develop  and,  if  needed, 
implement  an  appropriate  approach  to  prevent  or  handle 
causes  of  risk  that  could  result  in  significant  harm  or  loss. 
Typically,  risk  management  is  performed  for  project, 
organization,  or  product  developing  organizational  units. 

A  source  of  a  defect  such  that  if  it  is  removed,  the  defect  is 
decreased  or  removed. 

In  the  CMMI  Product  Suite,  a  management  role  at  a  high 
enough  level  in  an  organization  that  the  primary  focus  of  the 
person  filling  the  role  is  the  long-term  vitality  of  the 
organization  rather  than  short-term  project  and  contractual 
concerns  and  pressures.  A  senior  manager  has  authority  to 
direct  the  allocation  or  reallocation  of  resources  in  support  of 
organizational  process  improvement  effectiveness.  (See 
also  “higher  level  management.”) 

A  senior  manager  can  be  any  manager  who  satisfies  this 
description,  including  the  head  of  the  organization. 

Synonyms  for  “senior  manager”  include  “executive”  and 
“top-level  manager.”  However,  to  ensure  consistency  and 
usability,  these  synonyms  are  not  used  in  CMMI  models. 

In  the  CMMI  Product  Suite,  a  service  is  a  product  that  is 
intangible  and  non-storable.  (See  also  “product,”  “customer,” 
and  “work  product.”) 
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shared  vision 


software 

engineering 


solicitation 

special  cause  of 
process  variation 

specific  goal 


specific  practice 


stable  process 


staged 

representation 


stakeholder 


A  common  understanding  of  guiding  principles  including 
mission,  objectives,  expected  behavior,  values,  and  final 
outcomes,  which  are  developed  and  used  by  a  project. 

(1)The  application  of  a  systematic,  disciplined,  quantifiable 
approach  to  the  development,  operation,  and  maintenance 
of  software.  (2)  The  study  of  approaches  as  in  (1).  (See  also 
“hardware  engineering,”  and  “systems  engineering.”) 

The  process  of  preparing  a  package  to  be  used  in  selecting 
a  supplier  (contractor). 

A  cause  of  a  defect  that  is  specific  to  some  transient 
circumstance  and  not  an  inherent  part  of  a  process.  (See 
also  “common  cause  of  process  variation.”) 

A  required  model  component  that  describes  the  unique 
characteristics  that  must  be  present  to  satisfy  the  process 
area.  (See  also  “capability  level,”  “generic  goal,” 
“organization’s  business  objectives,”  and  “process  area.”) 

An  expected  model  component  that  is  considered  important 
in  achieving  the  associated  specific  goal.  The  specific 
practices  describe  the  activities  expected  to  result  in 
achievement  of  the  specific  goals  of  a  process  area.  (See 
also  “process  area”  and  “specific  goal.”) 

The  state  in  which  all  special  causes  of  process  variation 
have  been  removed  and  prevented  from  recurring  so  that 
only  the  common  causes  of  process  variation  of  the  process 
remain.  (See  also  “capable  process,”  “common  cause  of 
process  variation,”  “special  cause  of  process  variation,” 
“standard  process,”  and  “statistically  managed  process.”) 

A  model  structure  wherein  attaining  the  goals  of  a  set  of 
process  areas  establishes  a  maturity  level;  each  level  builds 
a  foundation  for  subsequent  levels.  (See  also  “maturity 
level”  and  “process  area.”) 

In  the  CMMI  Product  Suite,  a  group  or  individual  that  is 
affected  by  or  is  in  some  way  accountable  for  the  outcome 
of  an  undertaking.  Stakeholders  may  include  project 
members,  suppliers,  customers,  end  users,  and  others.  (See 
also  “customer”  and  “relevant  stakeholder.”) 
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standard 


standard  process 


statement  of  work 


statistical 

predictability 

statistical  process 
control 


statistical 

techniques 


statistically 
managed  process 


subpractice 


When  you  see  the  word  standard  used  as  a  noun  in  a  CMMI 
model,  it  refers  to  the  formal  mandatory  requirements 
developed  and  used  to  prescribe  consistent  approaches  to 
development  (e.g.,  ISO/IEC  standards,  IEEE  standards,  and 
organizational  standards).  Instead  of  using  standard  in  its 
common  everyday  sense,  we  use  another  term  that  means 
the  same  thing  (e.g.,  typical,  traditional,  usual,  or 
customary). 

An  operational  definition  of  the  basic  process  that  guides  the 
establishment  of  a  common  process  in  an  organization. 

A  standard  process  describes  the  fundamental  process 
elements  that  are  expected  to  be  incorporated  into  any 
defined  process.  It  also  describes  the  relationships  (e.g., 
ordering  and  interfaces)  among  these  process  elements. 
(See  also  “defined  process.”) 

A  description  of  contracted  work  required  to  complete  a 
project. 

The  performance  of  a  quantitative  process  that  is  controlled 
using  statistical  and  other  quantitative  techniques. 

Statistically  based  analysis  of  a  process  and  measurements 
of  process  performance,  which  will  identify  common  and 
special  causes  of  variation  in  the  process  performance  and 
maintain  process  performance  within  limits.  (See  also 
“common  cause  of  process  variation,”  “special  cause  of 
process  variation,”  and  “statistically  managed  process.”) 

An  analytic  technique  that  employs  statistical  methods  (e.g., 
statistical  process  control,  confidence  intervals,  and 
prediction  intervals). 

A  process  that  is  managed  by  a  statistically  based  technique 
in  which  processes  are  analyzed,  special  causes  of  process 
variation  are  identified,  and  performance  is  contained  within 
well-defined  limits.  (See  also  “capable  process,”  “special 
cause  of  process  variation,”  “stable  process,”  “standard 
process,”  and  “statistical  process  control.”) 

An  informative  model  component  that  provides  guidance  for 
interpreting  and  implementing  a  specific  or  generic  practice. 
Subpractices  may  be  worded  as  if  prescriptive,  but  are 
actually  meant  only  to  provide  ideas  that  may  be  useful  for 
process  improvement. 
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subprocess 


supplier 


sustainment 


systems 

engineering 


tailoring 


A  process  that  is  part  of  a  larger  process.  A  subprocess  can 
be  decomposed  into  subprocesses  and/or  process 
elements.  (See  also  “process,”  “process  description,”  and 
“process  element.”) 

(1 )  An  entity  delivering  products  or  performing  services 
being  acquired.  (2)  An  individual,  partnership,  company, 
corporation,  association,  or  other  service  having  an 
agreement  (contract)  with  an  acquirer  for  the  design, 
development,  manufacture,  maintenance,  modification,  or 
supply  of  items  under  the  terms  of  an  agreement  (contract). 

The  processes  used  to  ensure  that  a  product  can  be  utilized 
operationally  by  its  end  users  or  customers.  Sustainment 
ensures  that  maintenance  is  done  such  that  the  product  is  in 
an  operable  condition  whether  or  not  the  product  is  in  use  by 
customers  or  end  users. 

The  interdisciplinary  approach  governing  the  total  technical 
and  managerial  effort  required  to  transform  a  set  of 
customer  needs,  expectations,  and  constraints  into  a 
product  solution  and  to  support  that  solution  throughout  the 
product’s  life.  (See  also  “hardware  engineering”  and 
“software  engineering.”) 

This  includes  the  definition  of  technical  performance 
measures,  the  integration  of  engineering  specialties  toward 
the  establishment  of  a  product  architecture,  and  the 
definition  of  supporting  lifecycle  processes  that  balance 
cost,  performance,  and  schedule  objectives. 

Tailoring  a  process  makes,  alters,  or  adapts  the  process 
description  for  a  particular  end.  For  example,  a  project 
establishes  its  defined  process  by  tailoring  from  the 
organization’s  set  of  standard  processes  to  meet  the 
objectives,  constraints,  and  environment  of  the  project. 
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tailoring  guidelines 


target  profile 


target  staging 


Organizational  guidelines  that  enable  projects,  groups,  and 
organizational  functions  to  appropriately  adapt  standard 
processes  for  their  use.  The  organization’s  set  of  standard 
processes  is  described  at  a  general  level  that  may  not  be 
directly  usable  to  perform  a  process. 

Tailoring  guidelines  aid  those  who  establish  the  defined 
processes  for  projects.  Tailoring  guidelines  cover  (1) 
selecting  a  standard  process,  (2)  selecting  an  approved 
lifecycle  model,  and  (3)  tailoring  the  selected  standard 
process  and  lifecycle  model  to  fit  project  needs.  Tailoring 
guidelines  describe  what  can  and  cannot  be  modified  and 
identify  process  components  that  are  candidates  for 
modification. 

In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels  that  represent  an 
objective  for  process  improvement.  (See  also  “achievement 
profile”  and  “capability  level  profile.”) 

In  the  continuous  representation,  a  sequence  of  target 
profiles  that  describes  the  path  of  process  improvement  to 
be  followed  by  the  organization.  (See  also  “achievement 
profile,”  “capability  level  profile,”  and  “target  profile.”) 
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technical  data 
package 


technical 

requirements 

test  procedure 


traceability 


trade  study 


A  collection  of  items  that  can  include  the  following  if  such 
information  is  appropriate  to  the  type  of  product  and  product 
component  (e.g.,  material  and  manufacturing  requirements 
may  not  be  useful  for  product  components  associated  with 
software  services  or  processes): 

•  Product  architecture  description 

•  Allocated  requirements 

•  Product  component  descriptions 

•  Product-related  lifecycle  process  descriptions  if  not 
described  as  separate  product  components 

•  Key  product  characteristics 

•  Required  physical  characteristics  and  constraints 

•  Interface  requirements 

•  Materials  requirements  (bills  of  material  and  material 
characteristics) 

•  Fabrication  and  manufacturing  requirements  (for  both 
the  original  equipment  manufacturer  and  field  support) 

•  Verification  criteria  used  to  ensure  requirements  have 
been  achieved 

•  Conditions  of  use  (environments)  and  operating/usage 
scenarios,  modes  and  states  for  operations,  support, 
training,  manufacturing,  disposal,  and  verifications 
throughout  the  life  of  the  product 

•  Rationale  for  decisions  and  characteristics  (e.g., 
requirements,  requirement  allocations,  and  design 
choices) 

Properties  (attributes)  of  products  or  services  to  be  acquired 
or  developed. 

Detailed  instructions  for  the  setup,  execution,  and  evaluation 
of  results  for  a  given  test. 

A  discernable  association  among  two  or  more  logical  entities 
such  as  requirements,  system  elements,  verifications,  or 
tasks.  (See  also  “bidirectional  traceability”  and 
“requirements  traceability.”) 

An  evaluation  of  alternatives,  based  on  criteria  and 
systematic  analysis,  to  select  the  best  alternative  for 
attaining  determined  objectives. 
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training 


typical  work 
product 


unit  testing 


validation 


verification 

version  control 

work  breakdown 
structure  (WBS) 

work  product 


work  product  and 
task  attributes 


Formal  and  informal  learning  options,  which  may  include  in- 
class  training,  informal  mentoring,  Web-based  training, 
guided  self-study,  and  formalized  on-the-job  training 
programs.  The  learning  options  selected  for  each  situation 
are  based  on  an  assessment  of  the  need  for  training  and  the 
performance  gap  to  be  addressed. 

An  informative  model  component  that  provides  sample 
outputs  from  a  specific  practice.  These  examples  are  called 
typical  work  products  because  there  are  often  other  work 
products  that  are  just  as  effective  but  are  not  listed. 

Testing  of  individual  hardware  or  software  units  or  groups  of 
related  units.  (See  also  “acceptance  testing.”) 

Confirmation  that  the  product,  as  provided  (or  as  it  will  be 
provided),  will  fulfill  its  intended  use.  In  other  words, 
validation  ensures  that  “you  built  the  right  thing.”  (See  also 
“verification.”) 

Confirmation  that  work  products  properly  reflect  the 
requirements  specified  for  them.  In  other  words,  verification 
ensures  that  “you  built  it  right.”  (See  also  “validation.”) 

The  establishment  and  maintenance  of  baselines  and  the 
identification  of  changes  to  baselines  that  make  it  possible 
to  return  to  the  previous  baseline. 

An  arrangement  of  work  elements  and  their  relationship  to 
each  other  and  to  the  end  product. 

In  the  CMMI  Product  Suite,  a  useful  result  of  a  process.  This 
can  include  files,  documents,  products,  parts  of  a  product, 
services,  process  descriptions,  specifications,  and  invoices. 
A  key  distinction  between  a  work  product  and  a  product 
component  is  that  a  work  product  is  not  necessarily  part  of 
the  product.  (See  also  “product”  and  “product  component.”) 

In  CMMI  models,  you  will  see  the  phrase  work  products  and 
services.  Even  though  the  definition  of  work  product 
includes  services,  this  phrase  is  used  to  emphasize  the 
inclusion  of  services  in  the  discussion. 

Characteristics  of  products,  services,  and  project  tasks  used 
to  help  in  estimating  project  work.  These  characteristics 
include  items  such  as  size,  complexity,  weight,  form,  fit,  and 
function.  They  are  typically  used  as  one  input  to  deriving 
other  project  and  resource  estimates  (e.g.,  effort,  cost,  and 
schedule). 
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